Skip to content
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

Use Palantir format instead of Google Java Format #262

Merged
merged 1 commit into from
Apr 1, 2023

Conversation

MarkEWaite
Copy link
Collaborator

Use Palantir format instead of Google Java Format

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

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

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 MarkEWaite added the chore Reduces maintenance effort by changes not directly visible to users label Apr 1, 2023
@MarkEWaite MarkEWaite merged commit f818db6 into jenkinsci:master Apr 1, 2023
@MarkEWaite MarkEWaite deleted the format-with-palantir branch April 1, 2023 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Reduces maintenance effort by changes not directly visible to users
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants