org.sonar.l10n.py.rules.python.S5806.html Maven / Gradle / Ivy
This rule raises an issue when the name of a local variable matches the name of a builtin.
Why is this an issue?
Defining a variable with the same name as a built-in symbol will "shadow" it. That means that the builtin will no longer be accessible through its
original name, having locally been replaced by the variable.
Shadowing a builtin makes the code more difficult to read and maintain. It may also be a source of bugs as you can reference the builtin by
mistake.
It is sometimes acceptable to shadow a builtin to improve the readability of a public API or to support multiple versions of a library. In these
cases, benefits are greater than the maintainability cost. This should, however, be done with care.
It is generally not a good practice to shadow builtins with variables which are local to a function or method. These variables are not public and
can easily be renamed, thus reducing the confusion and making the code less error-prone.
Code examples
Noncompliant code example
def a_function():
int = 42 # Noncompliant; int is a builtin
Compliant solution
def a_function():
value = 42
Resources
Documentation
- Python documentation - Built-in Types
- Python documentation - Built-in Functions