10

I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE's (note 1).

Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?

My research points me to 'no', but a solution combining git hooks and Checkstyle/jrefactory might be possible.

So if 'no' to above, is there a tool/process that will perform the TBD process actions below?

The checkout process flow for User1 would be:

  1. git pull
  2. TBD process formats code to User1 style-1
  3. User1 works in their preferred IDE with style-1 settings

The commit workflow for User1 would be:

  1. User1 is ready to commit/push code
  2. TBD process formats code to standard format style-standard
  3. git push

Note 1: multiple IDE's = Eclipse, IntelliJ, Netbeans.

Note 2: My question differs from this question in that I'd like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.

Note 3: Acknowledging that this shouldn't be done for best-practices-reasons. However, if you grant that it's time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.

Community
  • 1
  • 1
JJ Zabkar
  • 3,792
  • 7
  • 45
  • 65
  • 1
    We use [Checkstyle](http://checkstyle.sourceforge.net/) here, which has plugins for the major IDEs, at least, and can also be integrated with CI build tools/repository hooks. Your best bet is to force everybody to edit/format everything pre-commit, because doing diffs in a different format is really difficult; at minimum, have the repository reject the commit if formatting the code turns up differences. – Clockwork-Muse May 23 '13 at 22:48
  • I agree that the "force everybody" pre-commit strategy is the most efficient; my question is intended to focus more on "is there a way to allow users to view/edit in one style and **automatically** commit in another style; if so, example...". My noob-ish git skill level has not yet facilitated a solution. – JJ Zabkar May 23 '13 at 22:50
  • ....I doubt it - for one thing, it's usually best for coders to review their changes before checkin (otherwise, you have 'blind' commits). At which point, you don't want the 'noise' of differing formatting rules. So your options are either to force the format _before_ diff/commit, or change the diff generators to format the code first (which they generally can't do, because formatting changes are a valid change....) – Clockwork-Muse May 23 '13 at 23:49

2 Answers2

13

First of all, you really shouldn't do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don't have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn't solve the fact that they'll have to read code in a codestyle they don't yet like, but it's a lot safer than having invisible automatic code changes; that's a major source of bugs.

Maybe you can use Eclipse's code formatter from the command line to apply a different codestyle. You'd have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You'd need hooks both for post-checkout and pre-commit, one to set up the user's codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn't include style differences in git diff (although they will show up in git diff --staged).

Again, you shouldn't do that.

Sergiu Dumitriu
  • 11,455
  • 3
  • 39
  • 62
  • agree on "decide upon one codestyle that everybody must use". Having everyone using their style and wish some program will transform it to a "standard" style can hardly work. Just like Eclipse's formatter, it can help in formatting some basic case but in most case it is making the code even uglier and harder to read. Developers have the responsibility to make their code follow a well-defined format. – Adrian Shum May 24 '13 at 04:59
  • And [checkstyle](http://checkstyle.sourceforge.net/) can enforce that style at build time, when integrated with Maven or Ant and used with a Continuous Integration server. – Sergiu Dumitriu May 24 '13 at 05:20
  • Clicked on this question because of the bounty, but all I have to say is +1 to this answer because **you really shouldn't do that** (although I recognize that may not be your choice). – eaj May 24 '13 at 18:23
  • Agree with the scolding; added Note 3. – JJ Zabkar May 27 '13 at 22:35
  • Re: All above-- I'm most familiar with Eclipse. Does IntelliJ or Netbeans provide similar functionality? – JJ Zabkar May 27 '13 at 22:37
  • 1
    @AdrianShum: You statement is exactly the given that I'm questioning. I agree with "Developers have the responsibility to make their code follow (one) well-defined format", but why does this mean there must be only one format for viewing and editing? The answer has historically been because our tools won't allow it. I'm questioning the state of those tools and assumptions. – JJ Zabkar May 27 '13 at 22:41
  • @SergiuDumitriu: Checkstyle was were I started looking, with CI in mind. But once I started questioning where & why I was enforcing a style--namely (1) readability in SCM for code compares and (2) flexibility in the developer's IDE for productivity, the value of a build-time solution lessened. My primary goals for this question are read-time-comparability and editor-time-productivity. – JJ Zabkar May 27 '13 at 22:47
  • 1
    I agree that we should not convert the code before commiting, but why not having a filtered view that let people enjoy the format they like? – Guillaume Aug 27 '14 at 13:12
  • > It is simple to configure IDEs to automatically apply the specified codestyle at every filesave
    IntelliJ and Eclipse have very different approaches to formatting. In practice, the only way to mimic Eclipse formatting in IntelliJ is to use a 3rd party plugin that invokes Eclipse for formatting.     – sesm Oct 24 '14 at 12:04
  • Not supporting individual styles is a productivity killer and it is clearly legacy thinking. When tech can make it possible, why not have a proper solution in place. Git pre-commit and post-checkout process be of great support here. – Raja Nagendra Kumar Feb 01 '21 at 02:46
7

I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:

Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes. So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:

smudge filter

And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):

clean filter

It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.

Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes

Chronial
  • 66,706
  • 14
  • 93
  • 99
  • Chronial: I think this is a start. Adding in @SergiuDumitriu's solution, it looks like this could be implemented end-to-end to solve the Eclipse user's problems. Do you know if similar IDE code formatting solutions exist for NetBeans or IntelliJ? – JJ Zabkar May 27 '13 at 22:49
  • 1
    ? The solution I presented does not depend on any IDE. – Chronial May 27 '13 at 23:59
  • @JJZabkar Just a warning if you are considering the code formatter in Eclipse: I have never found its formatting satisfactory: line breaking and indentation is done base on simple rules, hence the result is usually not helping in readability. Try to use it for a while and you know what I mean. – Adrian Shum May 28 '13 at 01:22
  • 1
    @AdrianShum I've been using Eclipse for years and had projects that essentially relied on standardized Eclipse formatter settings, with good success. Teams were able to find workaround for any shortcomings (i.e., `@formatter:off`). I agree with you on the 'unsatisfactory' evaulation, in that in order to achieve readable code, the same IDE+settings were required. – JJ Zabkar May 29 '13 at 23:31
  • @JJZabkar Well, I am relying on Eclipse's formatter for years, but I just rely it on its help in indentation etc. I have never been satisfactory with the result of "Ctrl-Shift-F". Good point for `@formatter:off` which is something that I overlooked :) – Adrian Shum May 30 '13 at 01:05