SLLS-544 fix: resolve 5 SonarQube code quality issues#706
SLLS-544 fix: resolve 5 SonarQube code quality issues#706sonarqube-agent[bot] wants to merge 1 commit into
Conversation
Fixed issues: - AZjr5v0K9TChwHguyc6P for java:S1874 rule - AZjr5v0K9TChwHguyc6Q for java:S1874 rule - AZjRjdx3592amupb0FPO for java:S117 rule - AZjRjdx3592amupb0FPM for java:S117 rule - AZjRjdx3592amupb0FPN for java:S117 rule Generated by SonarQube Agent (task: 10508ede-c62a-46ce-8414-5b33dbb97995)
hashicorp-vault-sonar-prod
Bot
changed the title
Summary
This PR removes deprecated API calls and fixes variable naming conventions in two test files, resolving 5 SonarQube violations. Changes are limited to test code only: deprecated What reviewers should knowScope: Test files only—no production code changes. Changes breakdown:
No behavior changes — all modifications are code quality cleanups with no functional impact.
|
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
There was a problem hiding this comment.
The 5 SonarQube fixes are all safe. The removals of setSeverity/setType from mockNoIssuesNoHotspotsForProject are correct — no test that calls that helper asserts those fields from the /api/rules/show.protobuf response (tests verifying rule type/severity set up their own explicit mock before calling the helper). The variable renames are clean and complete.
However, the Go code snippet in analyzeSimpleGoFileOnOpen also had its indentation changed (from \t to two spaces), and this change is not mentioned in the PR description and not related to any of the 5 SonarQube violations being addressed.
| if condition1 { | ||
| } else if condition1 { // Noncompliant | ||
| } |
There was a problem hiding this comment.
This indentation change is unrelated to the 5 SonarQube fixes and alters the actual Go source string passed to the analyzer.
The Java text block strips the common leading whitespace, which is 6 spaces (set by the closing """ on line 176). Before this change, the stripped content was \tif condition1 { (1 tab = 1 char). After this change it is if condition1 { (2 spaces = 2 chars).
This shifts every character position on affected lines by +1, breaking the column-sensitive assertions immediately below:
- Line 180:
tuple(3, 15, ...)— the{inif condition1 {moves from col 15 to col 16. - Line 181:
tuple(4, 11, 4, 21, ...)—condition1in} else if condition1moves from col 11–21 to col 12–22.
Either revert this indentation change and keep the original tab, or update the assertions to match the new positions.
| if condition1 { | |
| } else if condition1 { // Noncompliant | |
| } | |
| if condition1 { | |
| } else if condition1 { // Noncompliant | |
| } |
1 participant
This PR fixes 5 SonarQube violations across test files by removing calls to deprecated methods and correcting local variable naming conventions. The changes improve code quality by adhering to Java naming standards and eliminating deprecation warnings in ConnectedModeMediumTests and LanguageServerMediumTests.
View Project in SonarCloud
Fixed Issues
java:S1874 - Remove this use of "setSeverity"; it is deprecated. • MINOR • View issue
Location:
sonarlint-language-server:src/test/java/org/sonarsource/sonarlint/ls/mediumtests/ConnectedModeMediumTests.java:1308Why is this an issue?
Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.
What changed
This hunk removes the calls to the deprecated methods
setSeverity("MINOR")andsetType(Common.RuleType.SECURITY_HOTSPOT). By deleting these two lines, it directly resolves both deprecation warnings: the one about using the deprecatedsetSeveritymethod and the one about using the deprecatedsetTypemethod in the test fileConnectedModeMediumTests.java.java:S1874 - Remove this use of "setType"; it is deprecated. • MINOR • View issue
Location:
sonarlint-language-server:src/test/java/org/sonarsource/sonarlint/ls/mediumtests/ConnectedModeMediumTests.java:1309Why is this an issue?
Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.
What changed
This hunk removes the calls to the deprecated methods
setSeverity("MINOR")andsetType(Common.RuleType.SECURITY_HOTSPOT). By deleting these two lines, it directly resolves both deprecation warnings: the one about using the deprecatedsetSeveritymethod and the one about using the deprecatedsetTypemethod in the test fileConnectedModeMediumTests.java.java:S117 - Rename this local variable to match the regular expression '^[a-z][a-zA-Z0-9]*$'. • MINOR • View issue
Location:
sonarlint-language-server:src/test/java/org/sonarsource/sonarlint/ls/mediumtests/LanguageServerMediumTests.java:957Why is this an issue?
A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
Local variables and method parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern.
Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
What changed
This hunk renames the local variable 'OLD' to 'oldValue' and 'NEW' to 'newValue' at line 957-958 in a second test method, fixing the naming convention violation where uppercase local variable names like 'OLD' do not match the required pattern '^[a-z][a-zA-Z0-9]*$'.
java:S117 - Rename this local variable to match the regular expression '^[a-z][a-zA-Z0-9]*$'. • MINOR • View issue
Location:
sonarlint-language-server:src/test/java/org/sonarsource/sonarlint/ls/mediumtests/LanguageServerMediumTests.java:937Why is this an issue?
A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
Local variables and method parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern.
Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
What changed
This hunk renames the local variables 'OLD' and 'NEW' (which violate the naming convention requiring names to match '^[a-z][a-zA-Z0-9]*$') to 'oldValue' and 'newValue' respectively at line 937-938. It also updates the usages of these variables in the constructor call and setter call on the following lines.
java:S117 - Rename this local variable to match the regular expression '^[a-z][a-zA-Z0-9]*$'. • MINOR • View issue
Location:
sonarlint-language-server:src/test/java/org/sonarsource/sonarlint/ls/mediumtests/LanguageServerMediumTests.java:938Why is this an issue?
A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
Local variables and method parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern.
Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
What changed
This hunk renames the local variables 'OLD' and 'NEW' (which violate the naming convention requiring names to match '^[a-z][a-zA-Z0-9]*$') to 'oldValue' and 'newValue' respectively at line 937-938. It also updates the usages of these variables in the constructor call and setter call on the following lines.
SonarQube Remediation Agent uses AI. Check for mistakes.