Adopt automatic code style formatting

[nh13]

@tfenne @lbergelson @jacarey @pshapiro4broad

From recent memory, I have seen most pull requests have style issues (mine included) with anywhere between 20-80% of the comments related to code style. I suggest moving to using a code reformatter, for example google-java-format or an equivalent (top hit on google for me, hah!). I don't particularly care which one, as long as it's IDE-independent. Yes, the code may get uglier to some, but as always, there's a trade-off that were are currently making so I'd like to revisit that.

I think this would go a long way to reduce chatter on issues about style, and focus the conversations around substance.

[pshapiro4broad]

I think that's a great idea, and I agree that the solution shouldn't require an IDE.

google-java-format looks interesting, and there are notes here about how to add it to a gradle build.

In the past I've used checkstyle which works quite well, but it doesn't fix your code, it only tells you what needs fixing. (although there are plugins for ecplise and intellij that will auto-fix checkstyle errors)

[nh13]

For fun, I have a branch with code style updated on compile: #1197. Compile-time formatting is a little dangerous, as syntax errors can cause imports to be removed, but this forces folks to always have well formatted code. The other option is to use travis-ci to enforce it via the verifyGoogleJavaFormat task.

[nh13]

I know @tfenne will return next week from vacation, but @lbergelson or @jacarey care to weigh in?

[lbergelson]

I like the idea of having code style be more automated. I have a few concerns though.

1. Reformatting the whole of htsjdk at once is going to make the history much more annoying, this isn't necessarily a deal breaker but it's not great.
2. We want to be sure that it's uncommon for people to submit a PR and then discover they forgot to format things, ideally, we'd have easy to set up git hooks and instructions for how to set it up so that it always formats before committing.
3. Auto formatters can be really annoying if you and the formatter disagree and it's not very configurable. They're also not great when there are special cases that need special formatting.

[yfarjoun]

so, I'm not @lbergelson or @jacarey...but I have to say that I don't like the 2-space version...also the linter seems to chop lines in weird places...

[nh13]

@yfarjoun any reason you closed this?

[yfarjoun]

Sorry. Wrong button.

…

On Mon, Oct 15, 2018 at 3:44 PM Nils Homer ***@***.***> wrote: @yfarjoun <https://github.com/yfarjoun> any reason you closed this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1196 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACnk0uRRW3V0DA8g5VvdZ_PPMEecgRAYks5ulOWMgaJpZM4XX8JC> .

[magicDGS]

Some suggestions for this:

• Use codacy for automatic code-review for the push and to separate the code linting from the build in the checks (like that, it stops PRs to be blocked by this)
• I have some modifications of the Google style guide (settings for eclipse and IntelliJ) in this repo. Maybe it is a good idea to add something similar to the htsjdk repo and add to a programmers guide (either Wiki or README).

[pshapiro4broad]

Use codacy for automatic code-review for the push and to separate the code linting from the build in the checks (like that, it stops PRs to be blocked by this)

I have codacy enabled on a few repos but so far the reports haven't been very useful. Have you had better luck using it?

I have some modifications of the Google style guide (settings for eclipse and IntelliJ) in this repo. Maybe it is a good idea to add something similar to the htsjdk repo and add to a programmers guide (either Wiki or README).

Unless I'm mistaken, this doesn't address the need of not requiring an IDE to perform and fix code style issues. If it's decided that using an IDE can be required, there are many possible solutions.