Resolve SonarQube naming conflicts and code smell issues

[sonarqube-agent]

This PR was automatically created by the Remediation Agent's Scheduled backlog remediation feature.

Why these issues? All 5 issues were severity level BLOCKER, making them the highest priority for automated remediation. The fixes address fundamental naming convention violations that could cause confusion and maintainability issues, while preserving all existing functionality.

Fixed 5 SonarQube blocker issues in discord/app_commands by renaming class fields GUILD and USER to _GUILD_TYPE and _USER_TYPE to eliminate capitalization-only naming clashes with property methods, and refactored a cooldown decorator predicate to remove redundant return statements. These changes improve code clarity and eliminate false positives in static analysis.

View Project in SonarCloud

---

Fixed Issues

python:S1845 - Rename method "guild" to prevent any misunderstanding/clash with field "GUILD" defined on line 53 • BLOCKER • View issue

Location: discord/app_commands/installs.py:61

Why is this an issue?

Looking at the set of methods and fields in a class and finding two that differ only by capitalization is confusing to users of the class.

What changed

Renames the class-level fields GUILD and USER to _GUILD_TYPE and _USER_TYPE respectively. This eliminates all capitalization-only naming clashes: the guild property getter and setter methods clashed with the GUILD field, and the user property getter and setter methods clashed with the USER field. By renaming the fields to _GUILD_TYPE and _USER_TYPE, the names are now sufficiently distinct from the guild and user property methods, resolving all five capitalization-only naming conflicts including the guild setter which also conflicted with GUILD.

--- a/discord/app_commands/installs.py
+++ b/discord/app_commands/installs.py
@@ -53,2 +53,2 @@ class AppInstallationType:
-    GUILD: ClassVar[int] = 0
-    USER: ClassVar[int] = 1
+    _GUILD_TYPE: ClassVar[int] = 0
+    _USER_TYPE: ClassVar[int] = 1

python:S1845 - Rename method "guild" to prevent any misunderstanding/clash with field "GUILD" defined on line 53 • BLOCKER • View issue

Location: discord/app_commands/installs.py:66

Why is this an issue?

Looking at the set of methods and fields in a class and finding two that differ only by capitalization is confusing to users of the class.

What changed

Renames the class-level fields GUILD and USER to _GUILD_TYPE and _USER_TYPE respectively. This eliminates all capitalization-only naming clashes: the guild property getter and setter methods clashed with the GUILD field, and the user property getter and setter methods clashed with the USER field. By renaming the fields to _GUILD_TYPE and _USER_TYPE, the names are now sufficiently distinct from the guild and user property methods, resolving all five capitalization-only naming conflicts including the guild setter which also conflicted with GUILD.

--- a/discord/app_commands/installs.py
+++ b/discord/app_commands/installs.py
@@ -53,2 +53,2 @@ class AppInstallationType:
-    GUILD: ClassVar[int] = 0
-    USER: ClassVar[int] = 1
+    _GUILD_TYPE: ClassVar[int] = 0
+    _USER_TYPE: ClassVar[int] = 1

python:S1845 - Rename method "user" to prevent any misunderstanding/clash with field "USER" defined on line 54 • BLOCKER • View issue

Location: discord/app_commands/installs.py:70

Why is this an issue?

Looking at the set of methods and fields in a class and finding two that differ only by capitalization is confusing to users of the class.

What changed

Renames the class-level fields GUILD and USER to _GUILD_TYPE and _USER_TYPE respectively. This eliminates all capitalization-only naming clashes: the guild property getter and setter methods clashed with the GUILD field, and the user property getter and setter methods clashed with the USER field. By renaming the fields to _GUILD_TYPE and _USER_TYPE, the names are now sufficiently distinct from the guild and user property methods, resolving all five capitalization-only naming conflicts including the guild setter which also conflicted with GUILD.

--- a/discord/app_commands/installs.py
+++ b/discord/app_commands/installs.py
@@ -53,2 +53,2 @@ class AppInstallationType:
-    GUILD: ClassVar[int] = 0
-    USER: ClassVar[int] = 1
+    _GUILD_TYPE: ClassVar[int] = 0
+    _USER_TYPE: ClassVar[int] = 1

python:S1845 - Rename method "user" to prevent any misunderstanding/clash with field "USER" defined on line 54 • BLOCKER • View issue

Location: discord/app_commands/installs.py:75

Why is this an issue?

Looking at the set of methods and fields in a class and finding two that differ only by capitalization is confusing to users of the class.

What changed

Renames the class-level fields GUILD and USER to _GUILD_TYPE and _USER_TYPE respectively. This eliminates all capitalization-only naming clashes: the guild property getter and setter methods clashed with the GUILD field, and the user property getter and setter methods clashed with the USER field. By renaming the fields to _GUILD_TYPE and _USER_TYPE, the names are now sufficiently distinct from the guild and user property methods, resolving all five capitalization-only naming conflicts including the guild setter which also conflicted with GUILD.

--- a/discord/app_commands/installs.py
+++ b/discord/app_commands/installs.py
@@ -53,2 +53,2 @@ class AppInstallationType:
-    GUILD: ClassVar[int] = 0
-    USER: ClassVar[int] = 1
+    _GUILD_TYPE: ClassVar[int] = 0
+    _USER_TYPE: ClassVar[int] = 1

python:S3516 - Refactor this method to not always return the same value. • BLOCKER • View issue

Location: discord/app_commands/checks.py:398

Why is this an issue?

When a function is designed to return an invariant value, it may be poor design, but it shouldn’t adversely affect the outcome of your program. However, when it happens on all paths through the logic, it is surely a bug.

What changed

This hunk refactors the predicate function in _create_cooldown_decorator to have only a single return True statement instead of two separate ones. The original code had two code paths both returning True (when bucket is None and when retry_after is None), which triggered the code smell about a function always returning the same value on all return paths. By inverting the conditions and consolidating the logic, the function now has only one return True at the end, eliminating the redundant return statements while preserving the same behavior (raising CommandOnCooldown when appropriate, otherwise returning True).

--- a/discord/app_commands/checks.py
+++ b/discord/app_commands/checks.py
@@ -400,8 +400,5 @@ def _create_cooldown_decorator(
-        if bucket is None:
-            return True
-
-        retry_after = bucket.update_rate_limit(interaction.created_at.timestamp())
-        if retry_after is None:
-            return True
-
-        raise CommandOnCooldown(bucket, retry_after)
+        if bucket is not None:
+            retry_after = bucket.update_rate_limit(interaction.created_at.timestamp())
+            if retry_after is not None:
+                raise CommandOnCooldown(bucket, retry_after)
+        return True

Have a suggestion or found an issue? Share your feedback here.

---

SonarQube Remediation Agent uses AI. Check for mistakes.

[sonarqube-agent]

⚠️ This repository does not have a CODEOWNERS file. The PR has been created but has not been automatically assigned to any reviewer. To ensure PRs are reviewed promptly, consider adding a CODEOWNERS file to your repository.