-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FormattingStyle follow-up #2327
FormattingStyle follow-up #2327
Conversation
} | ||
this.newline = newline; | ||
this.indent = indent; | ||
} | ||
|
||
/** | ||
* Creates a {@link FormattingStyle} with the specified newline setting. | ||
* Creates a {@code FormattingStyle} with the specified newline setting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have changed this to @code
because this is within the documentation of FormattingStyle
, so linking to itself is probably not necessary.
The (somewhat dated) "How to Write Doc Comments for the Javadoc Tool" guide also says: "Use in-line links economically"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be inclined not to do this. To quote Google's internal Best Practices document on javadoc:
Any specific type mentioned in prose should be hyperlinked every time in that documentation block. Historical advice was to link once and only once, but using {@link} every time is simpler, future-proof, and more tool-friendly. IDEs and code indexers can recognize this as a reference to a specific API and make it navigable. As an example, if that API is renamed later, the tools should know to fix this reference.
(Comment applies throughout.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point about validating the referenced name makes sense, but to me that appears to be rather a workaround for missing Javadoc functionality (e.g. @code
tag which represents a reference).
Personally I still think in the HTML output the links can be distracting / confusing, giving the impression that they refer to a different, similarly named class.
I have reverted these @link
changes now though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice, just a small review
gson/src/test/java/com/google/gson/functional/FormattingStyleTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at these changes, it strikes me that it's kind of ugly to use null
to mean no formatting. Could we have FormattingStyle.NONE
instead? I think having empty strings for newline
and indent
should mean no formatting? Also, we should probably reject having an empty newline
with a non-empty indent
.
These changes are outside the scope of this PR but I think we should probably make them before freezing the API at the next release.
} | ||
this.newline = newline; | ||
this.indent = indent; | ||
} | ||
|
||
/** | ||
* Creates a {@link FormattingStyle} with the specified newline setting. | ||
* Creates a {@code FormattingStyle} with the specified newline setting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be inclined not to do this. To quote Google's internal Best Practices document on javadoc:
Any specific type mentioned in prose should be hyperlinked every time in that documentation block. Historical advice was to link once and only once, but using {@link} every time is simpler, future-proof, and more tool-friendly. IDEs and code indexers can recognize this as a reference to a specific API and make it navigable. As an example, if that API is renamed later, the tools should know to fix this reference.
(Comment applies throughout.)
Though currently |
I think that suggests that |
Currently after a gson/gson/src/main/java/com/google/gson/stream/JsonWriter.java Lines 727 to 729 in ef35a34
For space after Also, what about naming |
OK, well what do you think of this:
I agree that customizing what comes after |
Have reduced this now to Javadoc and minimal code changes. |
LGTM |
* FormattingStyle follow-up * Add links to FormattingStyle * Use Truth for FormattingStyleTest * Reduce pull request scope to Javadoc and minor code changes
* FormattingStyle follow-up * Add links to FormattingStyle * Use Truth for FormattingStyleTest * Reduce pull request scope to Javadoc and minor code changes
Follow-up for #2231
null
being used as formatting style