Explicit comparison to singleton can be unreadable
This code insight count one violation each time a condition use an explicit comparison to "none", "false" or "true" (using operators == or !=). Bad: if number == None: print("This works, but is not the preferred PEP 8 pattern") if number ! = None : print("This works, but is not the preferred PEP 8 pattern") if otherNumber == false print("yooo !") if otherNumber != false print("yooo !") if T_flag == True : print ( "This works, but is not the preferred PEP 8 pattern" ) if F_flag ! = True : print ( "This works, but is not the preferred PEP 8 pattern" ) good: if number is None : print ( "This works, but is not the preferred PEP 8 pattern" ) if not otherNumber print ( "yooo !" ) # or better : if not otherNumber and otherNumber is not None
print ( "yooo !" )
if not otherNumber
print ( "yooo !" )
if T_ flag :
print ( "PEP 8 Style Guide prefers this pattern" )
# or moire restrictive check (exclude assimiled True values like non nul or non empty values)
if T_ flag is True :
print ( "PEP 8 Style Guide prefers this pattern" )
if not F_ flag :
print ( "PEP 8 Style Guide prefers this pattern" )
Why you should care
Per the PEP 8 Style Guide, the preferred way to compare something to None is the pattern if Cond is None . This is only a guideline. It can be ignored if needed. But the purpose of the PEP 8 style guidelines is to improve the readability of code.
Python evaluates certain values as false when in a boolean context. A quick "rule of thumb" is that all "empty" values are considered false so 0, None, [], {}, '' all evaluate as false in a boolean context. So comparing to "false" may be confusing.
Moreover, conditions using Python booleans are easier to read and less error-prone. In most cases, they're also faster
Per the PEP 8 Style Guide, the preferred ways to compare something to True are the patterns if cond is True: or if cond: . This is only a guideline. It can be ignored if needed. But the purpose of the PEP 8 Style Guide is to improve the readability of code.
Business Impacts
It is recommended to avoid these in order to ensure the code is more readable and cost effective.
[nz_btn text="Cost" target="_self" animate="false" animation_type="ghost" color="green" 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
References
http://docs.quantifiedcode.com/python-code-patterns/readability/comparison_to_none.html https://google.github.io/styleguide/pyguide.html#Conditional_Expressions http://docs.quantifiedcode.com/python-code-patterns/readability/comparison_to_true.htmlAbout CAST and Highlight’s Code Insights
Over the last 25 years, CAST has leveraged unique knowledge on software quality measurement by analyzing thousands of applications and billions of lines of code. Based on this experience and community standards on programming best practices, Highlight implements hundreds of code insights across 15+ technologies to calculate health factors of a software.
For reference only. For the complete details please refer the original article
https://doc.casthighlight.com/alt_comparisontosingleton-avoid-explicit-comparison-to-singleton/
https://doc.casthighlight.com/alt_comparisontosingleton-avoid-explicit-comparison-to-singleton/
Comments