Explicit comparison to singleton can be unreadable

CostSoftware AgilityCode Readability

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” )

5362

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.

Cost

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.html

5362

About 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.

See featuresHow it works

c