This blog https://effectivesoftwaredesign.com/2010/12/22/identifying-anti-patterns/ titled “Identifying Anti-Patterns” discusses what it refers to “anti-patterns”, a category of common code practices that resemble the organizational structure provided by the use of design patterns, but are actually counterproductive and not a good design. I think that the existence of anti-patterns is interesting; in an effort to write code that is well structured and easy to follow, it is actually made worse. The blog post points out that anti-patterns are most commonly used by programmers who are inexperienced and end up writing code with bad design and bad performance, but it is also possible for experienced programmers to do well in implementing a good design, but at the cost of a significant sacrifice on performance. In general I think it would be common for the implementation of a design pattern to have some performance trade-off with readability and maintainability, so there must be some line as to where a design pattern would become an “anti-pattern” if it were to cause some level of a decrease in performance. Design patterns are commonly used for the sake of scalability so that a program with a well-structured foundation will be easier to maintain as it becomes larger, but these design patterns that are implemented during the beginning of the development of the program may seem like unnecessary anti-patterns that are unnecessarily abstract for the current scope of the program. It may be difficult to identify anti-patterns given that excuses and arguments can be made for why code should be implemented in a certain way. Over-complicating things has an impact on performance, but an organized foundation is well suited for a large project, and re-implementing a lot of code as a project grows would likely be more counterproductive than being careful from the beginning. There definitely are some practices that are objectively wrong, but this blog post does not go into any examples, and it is also possible that what may be identified as an anti-pattern could be a false positive. When there is a trade-off between design and performance, it makes the most sense for an anti-pattern to refer to a mistake that is ineffective in both areas.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

In this blog post https://medium.com/engineering-housing/nan-is-not-equal-to-nan-771321379694 “NaN is not equal to NaN!”, Dron Rathore discusses the IEEE standard of NaN being a value which is not equal to itself. The blog explains some of the definitions and implementations surrounding NaN. It is not an opinionated blog post, it is mainly for the sake of being an educational resource. My particular interest is the actual reason in the first place for why NaN is defined as not being equal to itself. The result of comparison must be a boolean, so the only options for trying to compare NaN to itself are to return true or false, or error and crash. In mathematics, NaN is effectively “undefined” or “indeterminate”, so something like 0/0 is undefined. The truth value of the equation 0/0 = 0/0 is also undefined; the operation of equality is not defined for values that are not defined themselves unless the operation itself is given additional definition to account for that case, which is what must be done for programming languages so that it results in a boolean value. The choice for that value to be false is peculiar and ultimately seems arbitrary, but it is useful for detecting values that are NaN; if (x == x) is false then x is NaN. This blog post does not directly give any feedback on the reason for this implementation of NaN, it merely describes it, but I would like to get some perspective on how the choice is made and how it is more logical to have NaN not equal to itself over an alternative implementation where it is. Comparisons involving NaN may still result in confusing outputs; infinity > NaN is false, for instance, and so is infinity <= NaN, but “not (infinity <= NaN)” is true. For the sake of software testing, NaN adds a lot of strange edge cases where assumptions about equality lead to contradictions. In these cases, or in any case where it is not okay for NaN to exist, it makes the most sense to just have errors instead of trying to deal with this unique behavior.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.