Change Java coding formatting to standard formatting #770

Closed
highsource opened this Issue Aug 17, 2016 · 20 comments

Projects

None yet

3 participants

@highsource
Contributor

I've noticed that my code formatting differs from your standard format. Could you please share the Eclipse code format? Otherwise there's a risk we'll get more conflicts/noise when diffing/merging.

@karussell
Member

That is indeed a problem but here we only use IntelliJ or NetBeans. Probably it would be wise to switch to a more standard format instead of this trouble (?)

@highsource
Contributor

Or I'd switch to IntelliJ. As far as I know there's no way to import IntelliJ format into Eclipse.

@highsource highsource closed this Aug 17, 2016
@karussell
Member

I'm really open to switch the format to some more common format as we have e.g. a different setting on the map matching project which is ugly.

@karussell
Member

I'm currently looking how other Java projects are doing this. Of course we can use some post-processing via maven, but I would not rely on this.

@karussell
Member

E.g. ElasticSearch simply relies on some textual guidlines: https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md#contributing-to-the-elasticsearch-codebase

  • Java indent is 4 spaces
  • Line width is 140 characters
  • The rest is left to Java coding standards
  • Disable “auto-format on save” to prevent unnecessary format changes.
  • Wildcard imports (import foo.bar.baz.*) are forbidden
  • Don't worry too much about import order. Try not to change it
@highsource
Contributor

We often have dual IDE projects (Eclipse/IntelliJ). So far we've found no way to import code format from IntelliJ into Eclipse. It is, however, possible to import from Eclipse into IntelliJ. There seems to be a some non-official solution for NetBeas as well.

@devemux86
Contributor
devemux86 commented Aug 17, 2016 edited

FWIW I always wondered about the "strange" GraphHopper formatting (e.g. with curly brackets).
Meaning why not using the standards, i.e. what Intellij / AS and other IDEs share by default.

@karussell
Member

The "strange" formatting came in the early days where I found brakets where open and close are in the same column more readable especially for beginners and then it stays as changing this is a bit harder as it breaks pull requests etc

But yes, let us change this now to a more standard thing

Still IntelliJ and NetBeans all have still different default settings so we need to define and share these settings somehow to make reformatting in different IDEs possible. Additionally we could run checkstyle. Maybe one could use @highsource suggestion and use an eclipse format (although I would hate to rely on Eclipse somewhere ;)), e.g. libgdx is doing exactly this https://github.com/libgdx/libgdx/wiki/Contributing#eclipse-formatter

Or just some plan textual guides es ElasticSearch is doing.

@oblonski do you know how we could solve this?

@devemux86
Contributor
devemux86 commented Aug 17, 2016 edited

Or just some plan textual guides es ElasticSearch is doing.

I'd vote for that, seems indeed more convenient.
FYI in Mapsforge and VTM we use the default Intellij / Android Studio format settings.

@karussell
Member
karussell commented Aug 19, 2016 edited

I have decided to move to standard Java code formatting provided by IntelliJ and provide some compatible Netbeans settings. All without the Eclipse plugin for now (but nothing decided). The move will happen soonish (after a bigger feature merge into master)

Let me know your experiences/ideas etc!

@karussell karussell reopened this Aug 19, 2016
@karussell karussell added this to the 0.8 milestone Aug 19, 2016
@devemux86
Contributor

@karussell 👍

@karussell karussell changed the title from Please share Eclipse code format in the documentation/Eclispe guide to Change Java coding formatting to standard formatting Aug 19, 2016
@karussell
Member

IntelliJ is just too clever. I was fighting with it and did not understand what was going on until I read this here

@devemux86
Contributor
devemux86 commented Sep 12, 2016 edited

If you're playing with IntelliJ this keymap can be handy.

The Ctrl+Alt+L (Reformat code) on whole folders / modules combined with Ctrl+Alt+O(Optimize imports) helped me organize Mapsforge + VTM repositories. 😄

@karussell
Member
karussell commented Sep 12, 2016 edited

Yeah, thanks.

Currently trying to make NetBeans config to match these IntelliJ default settings. I find some formatting defaults a bit strange e.g. arrays it puts the opening bracket on a new line, and netbeans gets confused by this ... maybe I'll still use netbeans as default config (as one can encode this in the pom.xml) and IntelliJ picks it up correctly anyway now ;) ... but NetBeans does also strange things converting all else { if } clauses into else if {} which might be identical but is really ugly. Oh, yeah ;)

@karussell
Member
karussell commented Sep 12, 2016 edited

Ok, this procedure is good enough IMO: I'm using now a NetBeans config in the pom.xml which comes very close to the default IntelliJ formatter but improves things a bit.

So the automated configured formatter of IntelliJ should work now although my configuration still forces the style before the change, somehow. Restarting and clearing caches and removing the ~/.Idea-XY folder didn't help. So if you have problems with IntelliJ formatting. Go to File->Settings->Editor->Code Style and deselect 'detect and use existing file indents for editing'. Let me know if you had this problem too.

Interesting that I stumbled over limitations in both IDEs. Generally speaking one can say that NetBeans applies the better defaults and IntelliJ is more fine grained configurable. And formatting is faster with NetBeans.

So now we are using the following simple settings:

  • Java indent is 4 spaces
  • Unix line endings (should be handled via git)
  • Line width is 100 characters (wide enough?)
  • The rest is left to Java coding standards but disable “auto-format on save” to prevent unnecessary format changes.
  • Currently we do not care about import section that much, avoid changing it

Something missing?

@karussell karussell added a commit that referenced this issue Sep 12, 2016
@karussell karussell use IntelliJ default formatting, slightly corrected manually and via …
…NetBeans, #770
ea1a8e2
@devemux86
Contributor
devemux86 commented Sep 13, 2016 edited

So if you have problems with IntelliJ formatting. Go to File->Settings->Editor->Code Style and deselect 'detect and use existing file indents for editing'.

I think Ctrl+Alt+L (Reformat code) overcomes that?

Something missing?

You wrote a well defined summary (could be posted in contribution guide too).

@karussell
Member
karussell commented Sep 13, 2016 edited

I think Ctrl+Alt+L (Reformat code) overcomes that?

This works only if autodetected style is disabled.

TODOs:

  • add to contributing guide
@karussell karussell added a commit that referenced this issue Sep 13, 2016
@karussell karussell define code formatting in contributing, #770 21063de
@karussell
Member

Ok, fixed this and closing here for now.

@karussell karussell closed this Sep 13, 2016
@karussell karussell added a commit that referenced this issue Sep 13, 2016
@karussell karussell note important change regarding code formatting #770 661c64a
@karussell karussell referenced this issue in graphhopper/map-matching Sep 19, 2016
Merged

Clean up MapMatching.java #69

@highsource
Contributor

I've started an Eclispe Code Styla Formatter for Graphhopper:
GraphHopper.Formatter.zip

This is based on Eclipse Built-In settings and this comment.

@karussell
Member

@highsource thanks - helpful! Maybe we should link in the contribution guide to this for Eclipse users?

@karussell karussell referenced this issue Oct 6, 2016
@karussell karussell improve test speed via import only once 261d01a
@karussell karussell added a commit to graphhopper/map-matching that referenced this issue Oct 10, 2016
@karussell karussell put code formatting into the root of pom.xml, related to graphhopper/… 2046f2b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment