When writing code, it is important to ensure that each statement serves a purpose and contributes to the overall functionality of the program. When
they have no side effects or do not change the control flow, they can either indicate a programming error or be redundant:
- The code does not behave as intended: The statements are expected to have an effect but they do not. This can be caused by mistyping,
copy-and-paste errors, etc.
- The statements are residual after a refactoring.
Exceptions
Intentionally empty statement
Statements such as pass
or ...
(ellipsis) are clearly meant to have no effect and may be used to indicate an
implementation is missing. No issue will be raised in this case.
Strings
Some projects use string literals as comments. By default, this rule will not raise an issue on these strings. Reporting on string literals can be
enabled by setting the rule parameter reportOnStrings
to true
.
def foo():
bar()
"""Some comment""" # Compliant by default. Noncompliant with "reportOnStrings" set to "true"
qix()
Operators
By default, this rule considers that no arithmetic operator has a side effect. Some projects may redefine operators and add a side effect. You can
list such operators in the rule parameter ignoredOperators
.
def process(p, beam):
"""
Apache Beam redefines "|" and ">>" operators and they have a side effect.
Thus for Apache Beam projects "ignoredOperators"should be set to "|,>>"
"""
p | "create" >> beam.Create() # Noncompliant by default