Skip to content

SONARJAVA-5719 S1176 Should have a separate message for undocumented type parameters.#5575

Merged
NoemieBenard merged 4 commits intomasterfrom
nb/sonarjava-5719-type-parameters
Apr 22, 2026
Merged

SONARJAVA-5719 S1176 Should have a separate message for undocumented type parameters.#5575
NoemieBenard merged 4 commits intomasterfrom
nb/sonarjava-5719-type-parameters

Conversation

@NoemieBenard
Copy link
Copy Markdown
Contributor

Add separate message for type parameters in rule S1176.

@hashicorp-vault-sonar-prod
Copy link
Copy Markdown
Contributor

hashicorp-vault-sonar-prod Bot commented Apr 16, 2026

SONARJAVA-5719

@sonar-review-alpha
Copy link
Copy Markdown
Contributor

sonar-review-alpha Bot commented Apr 16, 2026

Summary

This PR modifies rule S1176 (undocumented API) to use context-aware messages for undocumented parameters:

  • Classes, interfaces, and records now report "Document the type parameter(s)" when their generic type parameters lack documentation
  • Methods continue to report "Document the parameter(s)" for method parameters

The implementation adds a helper method getParamLabel() that checks the AST node type to select the appropriate message. Test expectations are updated to reflect the new wording, and a new test case verifies the fix works for Java records.

What reviewers should know

Start here: Read getParamLabel() (newly added around line 156) — it's the core logic deciding which message to use.

Key changes:

  • Line 130-131: Message construction now calls getParamLabel() and uses String.join() instead of Collectors.joining()
  • Lines 156-158: New helper method that returns "type parameter(s): " for class/interface/record, "parameter(s): " for everything else
  • Test file updates reflect the message change and add a record test case

Minor cleanup: Removed unused Collectors import and reformatted a switch statement (line 165-169) — these are style improvements, not behavior changes.

Reviewers should verify: The distinction between type parameters and method parameters is clear in the updated test cases, especially the record example around line 336.


  • Generate Walkthrough
  • Generate Diagram

🗣️ Give feedback

sonar-review-alpha[bot]

This comment was marked as resolved.

if (!undocumentedParameters.isEmpty()) {
context.reportIssue(this, reportTree, "Document the parameter(s): " + undocumentedParameters.stream().collect(Collectors.joining(", ")));
String label = getParamLabel(tree);
context.reportIssue(this, reportTree, "Document the " + label + undocumentedParameters.stream().collect(Collectors.joining(", ")));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can try to improve existing code: String.join(", ", undocumentedParameters) should do the same as the long expression with a stream.

* This is a Javadoc comment
*/
public class MyClass<T> implements Runnable { // Noncompliant {{Document the parameter(s): <T>}}
public class MyClass<T> implements Runnable { // Noncompliant {{Document the type parameter(s): <T>}}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about something like this?

  /**
   * Description.
   */
  public record MyRecord<U>(U a, int b) {
  }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add such a test I think. In addtion to that, Let's file a ticket that this rule should also flag record fields that do not have a description (b in the example will not trigger an issue).

sonar-review-alpha[bot]

This comment was marked as outdated.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a test for a record with fields and type parameters. If not, then let's add it. See the comment.

* This is a Javadoc comment
*/
public class MyClass<T> implements Runnable { // Noncompliant {{Document the parameter(s): <T>}}
public class MyClass<T> implements Runnable { // Noncompliant {{Document the type parameter(s): <T>}}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add such a test I think. In addtion to that, Let's file a ticket that this rule should also flag record fields that do not have a description (b in the example will not trigger an issue).

@sonarqube-next
Copy link
Copy Markdown

Copy link
Copy Markdown
Contributor

@sonar-review-alpha sonar-review-alpha Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! ✅

The new commit adds a single test case that covers the record type for the "type parameter(s)" message, completing the picture alongside the existing class test at line 70. The test is correct.

🗣️ Give feedback

@NoemieBenard NoemieBenard merged commit 8652ee2 into master Apr 22, 2026
16 checks passed
@NoemieBenard NoemieBenard deleted the nb/sonarjava-5719-type-parameters branch April 22, 2026 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants