[nz_btn text="Software Resiliency" link="http://casthighlight.wpengine.com/software-resiliency/" target="_self" animate="false" animation_type="ghost" color="black" size="small" shape="rounded" type="normal" hover_normal="fill" hover_ghost="fill" icon="icon-dashboard"][nz_btn text="Code Reliability" target="_self" animate="false" animation_type="ghost" color="black" size="small" shape="rounded" type="ghost" hover_normal="fill" hover_ghost="screen" link="http://casthighlight.wpengine.com/category/product/indicators-methodology/code-insights/software-resiliency/code-reliability/" icon="icon-code"]

Why you should care

Software development is an exact science and software doesn’t really like having doubts. Some programming languages have different ways to evaluate and compare manipulated information.  In the case of this code insight, a syntax confusion due to an implicit interpretation (e.g. using “==” instead of “===” in Javascript) may lead to bad data manipulation in production and possibly generates unwanted bugs and security flaws (by allowing the software to execute portions of code you wasn’t expecting).  An example to illustrate: it’s not because you say “true” (will be interpreted by the software as a string) that it really is (interpreted by the software as a state TRUE).

Business Impacts

Implied Typecasting is not extremely harmful to code but it is a sign of bad practice being displayed in development teams which can indicate symptoms of productivity issues.  It is helpful to prevent these issues by employing standard company policies which discourage such practices. Otherwise it can hamper the agile environment set by the company. [nz_btn text="Production Risk" target="_self" animate="false" animation_type="ghost" color="pink" size="small" shape="rounded" type="normal" hover_normal="opacity" hover_ghost="fill" link="http://casthighlight.wpengine.com/category/product/indicators-methodology/innovation/" icon="icon-office"]

CAST Recommendations

The good practice is to systematically use braces. Modern development environments can automatically add them when writing new code. Ideally, from a pure maintainability standpoint, the braces should also have a dedicated line for even greater readability.

References

JavaScript Patterns: Build Better Applications with Coding and Design Patterns, by Stoyan Stefanov (O’Reilly) https://code.tutsplus.com/tutorials/the-essentials-of-writing-high-quality-javascript–net-15145[nz_btn text="Style Guide" link="https://github.com/Kristories/awesome-guidelines" target="_self" icon="icon-book" animate="false" animation_type="ghost" color="turquoise" size="small" shape="rounded" type="ghost" hover_normal="fill" hover_ghost="fill"]

How we detect

This code insight counts the number of cases where a “falsy“ literal operand (false, 0, [], undefined, “”) is compared by using “==” or “!=”, or when a variable is implicitly verified (true or false) without using a comparison or logical operator (e.g. if(data) { … }). Depending on the usage density of this pattern, Highlight counts penalty points contributing to the Software Resiliency health factor for the scanned source file. [nz_btn text="See features" link="http://casthighlight.wpengine.com/outputs-analytics/" target="_self" icon="icon-stats" animate="false" animation_type="ghost" color="black" size="small" shape="rounded" type="normal" hover_normal="fill" hover_ghost="fill"][nz_btn text="How it works" link="http://casthighlight.wpengine.com/how-it-works/" target="_self" icon="icon-cog" animate="false" animation_type="ghost" color="black" size="small" shape="rounded" type="ghost" hover_normal="fill" hover_ghost="fill"]