Enforce coding style
dbwiddis opened this issue · comments
@dbwiddis : I think the priority could be to add the checkstyle plugin to the project in order to help contributors :-)
Some IDE are configured by default to use wildcards when optimizing imports.
Originally posted by @mathieucarbou in #327 (comment)
A very useful plugin we might want first is spotless-maven-plugin. It permits specifying a formatter and conventions, and automatically aligns the code to (most) conventions by running mvn spotless:apply.
Works for me :-)
So what's your code style? Sun default? Google? :)
None of both. I'm more pragmatic.
I was using intellij default style (disabling star imports and 2 char spacing). As many devs do also.
What was important for me is to facilitate contributions.
If we enforce a style that is so different than the IDE's defaults or exotic to the point that it forces people to change their IDE config to correctly contribute, then that's not good.
So whatever the style... As long as we can keep this philosophy (or have a really easy way to reformat)
Google is probably best to use. Currently at 2 character spacing which I believe is googles default.
I don't remember if 2 char spacing is the default in mlp but I agree for the switch to 2 char spacing if it is not already there. Using that since years already...
Star import and 2 char spacing and no trailing white space are I think the 3 things I change in my ide config
There's a ton of overlap in styles, and spotless makes it pretty frictionless for contributors. They do whatever, then run mvn spotless:apply and commit.
I use the Eclipse defaults which is pretty much the same as Google except 4 vs. 2 indent. Really there are only 3 choices you need to make and the rest is pretty consistent:
- Spaces vs. tabs (if you choose tabs I'll stop contributing 🤣 )
- Indent (2 vs. 4, looks like you've already got 2)
- Whether to put curly braces on same line or next line
I think you're pretty close to Google format already.
I'll look into doing this but let's prioritize getting 4.2 out the door first.
Ahah ;-)
Space + ident 2 + curly brace on same line + no star import then :-)
Agree.
I was looking to that yesterday... With the tremendous work you did we could issue a 4.2... But it would be nice of we could have #327 merged first...
Or we could do a rc3 and then 4.2 later also...
@dbwiddis If you want, I can look at this one since my focus at the moment has mainly been around the build itself. Based on last few threads, I think we are up to needing checkstyle, formatting, spotbugs, maybe a few others and given all can basically be automated it shouldn't really run into issues on how any contributor wants to be setup. I think you are further into the weeds on the code itself so probably better to assist the other PR(s) in that area for 4.2 than build related items. I'm a bit rate limited here - we both are. So I'm typicaly trying to push in 3 things a day with many others sitting idle and at a good pace so I expect to continue that most of this week. I'm on stay-cation so that helps.
As to 4.2, there is still something a bit off with this plugin that I hoped to figure out. I believe it is going to need a bit of cache magic which is pretty routine at this point to add but haven't been able to get deep enough to focus on that. Basically think a few threads here have highlighted windows potentially is the slowest with the plugin in relation to jgit. Its not much of a hit on newer virtualized machines but my trusty now 9 year old rig is consitently showing this plugin stopping the build and waiting for some time when it does nothing. Prior usage of profiling has shown this plugin out of 100+ I typically end up using at a broader scale is the slowest of the bunch. So I'm thinking some variation of caching where it checks the cache first for any suspected file changes at all before even attempting to run any license update provided cache has been built and not some force license event. Before I get there though, working on as much updates as possible so code base is relatively where it needs to be in case the issue is unrelated.
@mathieucarbou I think the following sequence is best:
sounds like a good plan to me 👍
I did apply default google rules from checkstyle 9.3 (still jdk 8 compatible copy). It doesn't outright have any issues that cause failure. It does have large number of warnings. A few of which are easily addressed. Main ones thus far is 100 line limit google uses is I think overdue for going to 120 given screen resolutions these days (if not more but that seems practical and what I've been using for a few years in google+ style). The other easy one is import order so I ran impsort plugin manually to address that. Since there are no outright failures on the check, we are really ok to bring that in and then just address run of checkstyle:checkstyle to see what warnings can be easily addressed. After these 2 items, the list isn't really that bad. Still has some > 120 issues, some package violations, javadocs and a few others that look like they can be easily cleared but not harmful with addition of the checkstyle check. That is assuming at least initially we don't make warnings fail.
@mathieucarbou I think the following sequence is best:
- Get Add feature to ignore git commits by id #327 merged
- Release a rc3
- Let @hazendaz troubleshoot performance/cache issues, and tweak build automation, but otherwise minimize new features
- Release 4.2 when we think it's production ready
Little changes:
@dbwiddis @hazendaz : little rollback of idea.... I have tried the Google Style and it is not suitable at all... It forces a wrong wrapping and alignment, especially for method calls and definition and a lot of wrapping too. I hate that because there are many cases where alignment and wrapping has to be up to the dev for readability.
So let's stick with the default Intellij style (perhaps closer to sun then ?) but:
- tab size 2
- indent 2
- continuous indent 4
- imports organized like IntelliJ defaults
I added the styles in PR #349 (IDEA + EditorConfig), reformatted the imports and formatted the few classes that needed a code reformat.
Closing - added a commit on master branch.