Switch to Palantir Java Format #506
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 1, 2023
MarkEWaite
added a commit
to MarkEWaite/elastic-axis-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
6 tasks
MarkEWaite
added a commit
to MarkEWaite/embeddable-build-status-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
Closed
6 tasks
MarkEWaite
added a commit
to MarkEWaite/implied-labels-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
6 tasks
MarkEWaite
added a commit
to MarkEWaite/nodelabelparameter-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
6 tasks
MarkEWaite
added a commit
to jenkinsci/elastic-axis-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
MarkEWaite
added a commit
to jenkinsci/implied-labels-plugin
that referenced
this pull request
Apr 1, 2023
From jenkinsci/cloud-stats-plugin#68 : Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter. For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule. For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase. The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in jenkinsci/plugin-compat-tester#506 and the results are far better than Google Java Format. As the Zen of Python states: > Practicality beats purity
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter.
For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule.
For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase.