Skip to content

SONARJAVA-5501 Implement check for syntax in Markdown comments S7474#5152

Merged
romainbrenguier merged 13 commits intomasterfrom
romain/new-rule/markdown-javadoc-syntax
May 19, 2025
Merged

SONARJAVA-5501 Implement check for syntax in Markdown comments S7474#5152
romainbrenguier merged 13 commits intomasterfrom
romain/new-rule/markdown-javadoc-syntax

Conversation

@romainbrenguier
Copy link
Copy Markdown
Contributor

@romainbrenguier romainbrenguier commented May 14, 2025

@romainbrenguier romainbrenguier force-pushed the romain/new-rule/markdown-javadoc-syntax branch 5 times, most recently from 7bf1828 to f60597a Compare May 15, 2025 07:09
@romainbrenguier romainbrenguier marked this pull request as ready for review May 15, 2025 07:26
@@ -0,0 +1,129 @@
package checks;

// Noncompliant@+3 {{replace HTML syntax with Markdown syntax in javadoc}}
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.

It would be reallly nice to have secondary locations and quickfixes. If it seems doable, but too much work, then maybe a second PR would be an option?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Secondary locations is probably easily doable but quickfixes probably much more difficult. I'll look at a solution for secondary locations first.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Actually secondary locations cannot be done because the Location class requires a Tree syntax node, but we don't have that inside java comments.


// Noncompliant@+2
/// Here is a list:
/// <ul>
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.

Is <ol> also in scope of this PR?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I can add it


@Override
public List<Tree.Kind> nodesToVisit() {
return Arrays.asList(PublicApiChecker.apiKinds());
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.

Starting iteration will have the effect of skipping dangling markdown docs, right? I think this is a good behavior and we should have a test for this, for example, the following code is compliant:

  public void dangling() {
    // Compliant, because it is not attached to a place where JavaDocs are legal.

    /// Some text appears in <i>italic</i>.
  }

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, I'll add a test

}
}

record Position(int lineNumber, int columnNumber) {
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.

There is an existing class with the same name org.sonar.plugins.java.api.location.Position and it is 1-based. This one is 0-based right. It may get confusing in future.

for (SyntaxTrivia trivia : markdownJavadoc) {
String comment = trivia.comment();
Matcher matcher = NON_MARKDOWN_JAVADOC_PATTERN.matcher(comment);
for (Pair<Integer, Integer> range : rangeOfNonQuotedCode(comment)) {
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.

There are lots of custom solutions for locations and ranges in text here. Have you considered using existing Position and Range classes? If they are not appropriate, have you considered extracting the utilities that you wrote into a separated reusable subclasses?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I will rewrite that part using the existing LineColumnConverter utility.

@romainbrenguier romainbrenguier force-pushed the romain/new-rule/markdown-javadoc-syntax branch 3 times, most recently from b06eb77 to 07dcc14 Compare May 16, 2025 06:26
Matcher matcher = NON_MARKDOWN_JAVADOC_PATTERN.matcher(comment);
for (Pair<Integer, Integer> range : rangeOfNonQuotedCode(comment)) {
LineColumnConverter lineColumnConverter = new LineColumnConverter(comment);
List<Pair<Integer, Integer>> rangeOfNonQuotedCode = rangeOfNonQuotedCode(comment);
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.

Quoted text complicates this check in a few places. Did you consider preprocessing comment by replacing quoted ranges with, say, (space), so that regex matching can be done without considering ranges?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I thought about it, then thought ranges would be better. In the end, you are right, ranges are too complicated. Replacing with space makes this much simpler.

return toPos(absolutSourcePosition).toPosition();
}

public record Pos(int line, int columnOffset) {
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.

Since we're here, let's put a JavaDoc here explaining what's 1-based and what's 0-based.

}

/**
* Represent the position in a source String.The first character is at {@code line} 1, and {@code columnOffset} 0.
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.

Space after full stop.

@romainbrenguier romainbrenguier force-pushed the romain/new-rule/markdown-javadoc-syntax branch from c4d522c to de6ed6f Compare May 19, 2025 09:39
@sonarqube-next
Copy link
Copy Markdown

@romainbrenguier romainbrenguier merged commit c01d9ba into master May 19, 2025
15 checks passed
@romainbrenguier romainbrenguier deleted the romain/new-rule/markdown-javadoc-syntax branch May 19, 2025 11:35
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