2023-08-07 14:45:53 +02:00
This rule raises an issue when the name of a local variable matches the name of a builtin.
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
== Why is this an issue?
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
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.
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
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.
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
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.
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
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.
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
=== Code examples
2021-04-28 18:08:03 +02:00
2023-08-07 14:45:53 +02:00
==== Noncompliant code example
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
[source,python,diff-id=1,diff-type=noncompliant]
2021-04-28 16:49:39 +02:00
----
def a_function():
int = 42 # Noncompliant; int is a builtin
----
2021-04-28 18:08:03 +02:00
2023-08-07 14:45:53 +02:00
==== Compliant solution
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
[source,python,diff-id=1,diff-type=compliant]
2021-04-28 16:49:39 +02:00
----
def a_function():
value = 42
----
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
== Resources
2021-04-28 16:49:39 +02:00
2023-08-07 14:45:53 +02:00
=== Documentation
* Python documentation - https://docs.python.org/3.8/library/stdtypes.html[Built-in Types]
* Python documentation - https://docs.python.org/3/library/functions.html[Built-in Functions]
2021-04-28 18:08:03 +02:00
2021-06-02 20:44:38 +02:00
2021-06-03 09:05:38 +02:00
ifdef::env-github,rspecator-view[]
2021-09-20 15:38:42 +02:00
'''
== Implementation Specification
(visible only on this page)
2023-05-25 14:18:12 +02:00
=== Message
Rename this variable; it shadows a builtin.
=== Highlighting
Primary:
* The first definition of a variable shadowing a builtin in a local scope (function)
Secondary:
* Any other assignment to the variable.
* message: "Variable also assigned here."
2021-09-20 15:38:42 +02:00
2021-06-08 15:52:13 +02:00
'''
2021-06-02 20:44:38 +02:00
== Comments And Links
(visible only on this page)
2023-05-25 14:18:12 +02:00
=== relates to: S2137
=== on 30 Apr 2020, 19:12:03 Nicolas Harraudeau wrote:
This rule is similar to RSPEC-2137 but it is a code smell because shadowing builtins will not make your code crash most of the time.
2021-06-03 09:05:38 +02:00
endif::env-github,rspecator-view[]