-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Improve resiliency to auto-formatting in server #48450
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
Improve resiliency to auto-formatting in server #48450
Conversation
Make a number of changes so that code in the `server` directory is more resilient to automatic formatting. This covers: * Reformatting multiline JSON to embed whitespace in the strings * Move some comments around to they aren't auto-formatted to a strange place. This also required moving some `&&` and `||` operators from the end-of-line to start-of-line`. * Turn of formatting of data tables in `HyperLogLogPlusPlus`. This also required a checkstyle suppression. * Add helper method `reformatJson()`, to strip whitespace from a JSON document using XContent methods. This is sometimes necessary where a test is comparing some machine-generated JSON with an expected value.
These have moved to PR elastic#48553.
I've moved the JSON-related changes in this PR to #48553 in order to reduce the number of changes here. |
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
@@ -46,6 +46,10 @@ | |||
<suppress files="client[/\\]rest-high-level[/\\]src[/\\]test[/\\]java[/\\]org[/\\]elasticsearch[/\\]client[/\\]documentation[/\\]WatcherDocumentationIT.java" id="SnippetLength" /> | |||
<suppress files="modules[/\\]reindex[/\\]src[/\\]test[/\\]java[/\\]org[/\\]elasticsearch[/\\]client[/\\]documentation[/\\]ReindexDocumentationIT.java" id="SnippetLength" /> | |||
|
|||
<!-- These use `// tag::` and `// end::` just to turn off auto-formatting, but | |||
as they have long lines the trigger the SnippetLength check --> | |||
<suppress files="server[/\\]src[/\\]main[/\\]java[/\\]org[/\\]elasticsearch[/\\]search[/\\]aggregations[/\\]metrics[/\\]HyperLogLogPlusPlus.java" id="SnippetLength" /> |
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 think that's an important check for the documentation I don't think we should be turning it off
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.
HyperLogLogPlusPlus.java
doesn't have any existing doc snippets, so right now it's safe to turn off the check for this file only. I suppose I could have reformatted the tagged sections to meet the width limit, but I didn't want to mess around the file in that way. I could add some comments in the file to explain the situation about formatting in greater detail? What do you think?
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.
This seems like a hack. I don't think we should mark something as a doc snippet if it isn't intended to be used in the docs. What about that file does not auto format well? Is there anything we can change about the format rules to make it better?
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 think "hack" is a fair assessment. However, the Eclipse formatter doesn't have support for recognising tables of data (it's the sole feature from the Google formatter than I miss - at least, I'm sure I read that somewhere), so the arrays of data get spread over many, many, many lines. Now, you could argue that this is irrelevant - semantically it makes no difference - but I didn't feel comfortable making that call.
You also can't define multiple tags for disabling and enabling the formatter, and we need to be able to use them for legitimate docs snippets.
The other option is to alter the source to build up the data arrays in pieces and then combine them. This is altering the source to please the compiler, which isn't great. Or define the data in text files or some such, and parse them, which is also a poor option.
...actually, thinking about it again, I suppose we could change the formatter config to only wrap where necessary in array initializers. That would be perfect for HyperLogLogPlusPlus.java
, but probably worsen readability for other arrays in the codebase. We'd then be configuring formatter for the exceptional cases.
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.
@rjernst I've taken a new approach to HyperLogLogPlusPlus
, by excluding it from being formatted automatically. I've applied to formatter to the rest of the file, for consistency, but left the data tables alone.
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.
LGTM in general do have once concern about check style
@elasticmachine run elasticsearch-ci/1 |
Still looking for an approval on this one. |
I had added doc snippet tags to HyperLogLogPlusPlus in order to stop the data tables being mangled when we come to automatically format the codebase. However, since the lines of code were longer than 76 characters, I also added a Checkstyle suppression. That's a slippery slope, however, so instead I've reformatted the long lines and removed the suppression.
Don't automatically reformat HyperLogLogPlusPlus. It's the cleanest way to avoid mangling the data tables it contains, without also hacking about with doc tag snippets, manual reformatting or checkstyle exclusions.
@elasticmachine run elasticsearch-ci/2 |
Any more review comments on this? |
build.gradle
Outdated
@@ -114,6 +114,10 @@ subprojects { | |||
|
|||
spotless { | |||
java { | |||
if (project.path.equals(':server')) { |
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.
Would be better to just add this to server/build.gradle
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 didn't think that would work, but turns out it does, which is much tidier, thank you. Unfortunately, I then had to wrap the config in a try/catch because unless a project opts-in to formatting, the spotless()
method doesn't exist. I can removed the extra cruft once we enable formatting.
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 added a minor comment, no need for another review.
Make a number of changes so that code in the `server` directory is more resilient to automatic formatting. This covers: * Reformatting multiline JSON to embed whitespace in the strings * Move some comments around to they aren't auto-formatted to a strange place. This also required moving some `&&` and `||` operators from the end-of-line to start-of-line`. * Add helper method `reformatJson()`, to strip whitespace from a JSON document using XContent methods. This is sometimes necessary where a test is comparing some machine-generated JSON with an expected value. Also, `HyperLogLogPlusPlus.java` is now excluded from formatting because it contains large data tables that don't reformat well with the current settings, and changing the settings would be worse for the rest of the codebase.
Backport of #48450. Make a number of changes so that code in the `server` directory is more resilient to automatic formatting. This covers: * Reformatting multiline JSON to embed whitespace in the strings * Move some comments around to they aren't auto-formatted to a strange place. This also required moving some `&&` and `||` operators from the end-of-line to start-of-line`. * Add helper method `reformatJson()`, to strip whitespace from a JSON document using XContent methods. This is sometimes necessary where a test is comparing some machine-generated JSON with an expected value. Also, `HyperLogLogPlusPlus.java` is now excluded from formatting because it contains large data tables that don't reformat well with the current settings, and changing the settings would be worse for the rest of the codebase.
Make a number of changes so that code in the
server
directory is more resilient to automatic formatting. This covers:place. This also required moving some
&&
and||
operators from theend-of-line to start-of-line`.
Turn of formatting of data tables inHyperLogLogPlusPlus
. This alsorequired a checkstyle suppression.
HyperLogLogPlusPlus
from being formatted. It would format OK if the rules for wrapping array contents were set to "wrap when necessary", but that would be worse for the rest of the codebase. Instead, I've applied to formatter to the rest of the file, for consistency, but left the data tables alone.reformatJson()
, to strip whitespace from a JSONdocument using XContent methods. This is sometimes necessary where
a test is comparing some machine-generated JSON with an expected
value.