On Thu, Feb 25, 2021 at 1:46 AM Liam Newman <bitwise...@gmail.com> wrote: > > Thanks you two, for clearly describing the issue that I'm attempting to > address.
You're welcome! As I mentioned, I've done this a few times and have learned what it takes to make the changes stick across a large number of developers. > Formatting issues will fail the build, source remains unchanged. > Users may run "mvn spotless:apply" to automatically fix formatting. > This command is easy and short. When "spotless:check" fails it > specifically tells users to run "mvn spotless:apply" to fix formatting. This sounds great! +1 for Spotless. I have been using it for years and have had nothing but positive experiences with the project and maintainer. > Note: I am using the eclipse formatter rather than to google formatter My recommendation is to use the Google Java formatter, but not because I have any personal preference for the Google style. Rather my reasoning is as follows. My experience with the Eclipse JDT formatter is that while it can be made to format the majority of code at high quality, this requires significant tweaking of the configuration options (as you have seen). Tweaking opens up the door to endless subjective debates (as you have also seen): > If anyone disagrees with that evaluation, feel free to say so and > explain why. Having to spend time tweaking formatting configuration options means increased development time. Having to spend time subjectively debating the results of those tweaks in a PR increases review time. These outcomes directly go against the stated goals from my previous message: to reduce development time and to reduce review time. While the Google Java formatter implies a more drastic transition, it generally formats the majority of code at high quality without requiring tweaking. Indeed, that it and Black are _not_ tweakable eliminates the endless subjective debates that are typically associated with formatting changes. In this way, it serves the two goals of reducing development time and reducing review time. A transition like this will be disruptive no matter which way you slice and dice it. Better to bite the bullet and take most of the disruption up front in order to maximize the long-term gain. An anecdote: My company has been using the Google Java formatter since 2017, and most complaints stopped after 2018. Since 2019 nobody at my company even thinks about formatting: the Google Java formatter is Good Enough™ the majority of the time, it is consistently enforced, and it is not up for debate. People focus on the logic, not the formatting, just as intended. If you pick the Eclipse JDT formatter, you'll be focusing on tweaking formatting configuration and subjectively debating formatting preferences for years to come. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp6p570_tW0icw5G8o%2Bgx11ufYrgJ%3DndmzQxcXXiFY%3DzA%40mail.gmail.com.
