I'm currently working at a place that may be looking at forcing developers to use an automated code formatter on version control check-in. I'm looking for developers opinions on the advantages and disadvantages of doing this ... how you think it would help or hinder developers. My specific case involves Java/JSPs, but I think the question could apply to any language.

  • JSP auto-reformat? That includes HTML/XML code and reformatting that can very easily break/change the resulting output. Jul 14 '11 at 14:40

I think it's very important to do this. Here's why:

  • It makes your source control diffs show just actual code changes, and all but eliminates "diff noise" due to whitespace and other insignificant formatting choices
  • It makes all code more similar, so that devs are more comfortable pairing and sharing the code bases

If you do it, I would recommend everyone check all code in, then one person does a reformat over the whole code base, then checks it all back in so there's one "giant" change set for formatting (that everyone can ignore), but after that, all diffs are real code diffs.

If you do it bit by bit, you'll be mixing real code changes with formatting changes and things will get unnecessarily messy in change land.

  • 1
    Biting the bullet on a global change is really the best way, I agree; get it done and no one has to worry about it ever again. Jul 12 '11 at 15:37
  • ... until you change your style convention.
    – Nerdfest
    Jul 13 '11 at 11:24
  • 1
    @Nerdfest Then you apply your new convention on all your project in a single commit. That's no big deal.
    – gizmo
    Jul 14 '11 at 14:10
  • 2
    Your "diff" tool kind of sucks if it can't handle whitespace changes properly. Jul 14 '11 at 14:33
  • 2
    There are always going to be exceptions where a slightly different format is likely cleaner than the prescribed style. Auto-converting can thus often hide the intent of certain code blocks, which is effectively just as good as adding a defect to the code. Jul 14 '11 at 14:42

I'm going to toss my own answer here as people only seem to be adding advantages. What I see as disadvantages are:

  • Eliminates the ability to do 'better' than the auto-formatter ... it will undo your cleaner formatting. An example of this would be column-based parameter declarations, lists of discrete additions of objects, etc.
  • Creates a resistance to changing style conventions as these will now create large misleading diff changes.
  • Removes the ability to do any 'special-case' formatting where an alternate format would make code more readable.
  • It ties you into using IDEs which support exactly the reformatting features you need. In another IDE is missing one of the options you need, it will cause at least some problems.
  • It becomes problematic sharing a writable code repository with an external group unless they use exactly the same format conventions as your group (They usually will, but not always).
  • There are always going to be exceptions where a slightly different format is likely cleaner than the prescribed style. Auto-converting can thus often hide the intent of certain code blocks, which is effectively just as good as adding a defect to the code.

Simply put, a non-automated set of conventions sets minimum style/readability requirements, where automated conventions set a minimum and a maximum.

I remember looking at VB (version 5 maybe) and finding one of the most annoying things about it was that it would forcibly reformat my code and remove things above and beyond its basic formatting.

  • One formating convention over another rarely gives any benefit if it comes at the expense of consistency. You get use to it. Follow Bohemian's advice and create a grace period to help determine the formating styles and then stick with them. Changing the format should not be taken lightly anyway.
    – JeffO
    Jul 12 '11 at 14:24
  • 3
    @Jeff, I don't believe he's advocating inconsistent code formatting, but rather consistent code formatting that is difficult to automate. For example, many coding styles specify aligning columns in an aesthetic manner when you have several lines of related data together. This greatly enhances readability, but is very difficult to automate definitions of "aesthetic" or "related." That's the reason some code formatters will allow manual formatting to override under certain circumstances. Jul 12 '11 at 15:07
  • 1
    Its far better to have consistent format 99.9% of the time and put up with the odd bit you personally don't like, than to put up with an undisciplined mismash. I probably depends how disciplined the team is where the balance lies. If you stick to the established norms for a language, all decent editors/IDEs will be capable of formating that way. If you insist on moving from the norms, you will have trouble.
    – mattnz
    Jul 14 '11 at 23:26

I find that forced code formatting is great. It allows a developer to traverse the entire corpus of code without having their eyes bounce everywhere. Also having this standard in place helps novice developers break bad habits.


Primary disadvantage is losing custom formatting where it really matters.

Imagine a typical sanity check if() that will fail if any of the specific conditions is present but not fulfilled...

      (user.id == TEST_ID)
         (user.id == UserID)
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

This is readable thanks to reasonable indenting following the logical structure of the conditions.

Now your automated tool has no clue about logical separation of different conditions into related lines. It sees no reason why each clump 3-4 conditions in one line and split the next condition in half. Or it will split it, one comparison expression per line. It may even look prettier on screen but the logic will be lost.

  • This is mess, my positron brain just melted. So much inconsistency with whitespace around ( and ). That's exactly why we need machines to format the code. And you could always put single line comment before/after (depends on your convention) to force condition grouping. It would also be helpful to explain reader the business rules behind this conditions - right in this single line comments. Aug 29 '19 at 10:11
  • @ŠtefanOravec: Run this through an autoformatter and apply these comments. See if it's more readable. Test user - always. Human users with valid usernames. Emulated users - only external sources. Email, if present, must be valid. Human users must have a phone number; emulated - must not. See how your single-line comments align with the autoformatted code.
    – SF.
    Aug 29 '19 at 11:49

I've added an answer with disadvantages, and I'll throw in what I consider a big advantage as well.

When you use an automated code reformat on commit, it does actually opens up the possibility of personal preference variations without the usual effect of having your preferences inflicted on others. You can have your IDE format code to a common standard on commit, but display it to you in your preferred format without affecting others.

This to me is almost the Holy Grail of convention based coding ... you get the advantages of a common code format, but still allow personal preferences to be supported without conflicts.


It depends on your needs but some contraints are quite helpful, e.g. every if() should be followed by curly braces, since it's quite easy to get such an if wrong if you're refactoring.

Consider that case:

if( x == 0 ) 
   return foo;
//do something else
return bar;

If you now want to add some logging to the if case you might accidentially write:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

And suddently your method always returns foo.

Edit: that's not on automatic formatting but rather style checking. Sorry if that answer was off topic as well. :)

  • That's more a code style thing, not a formatting thing. There are build tools for that.
    – Bohemian
    Jul 12 '11 at 12:44
  • @Bohemian, you're right, I misread the question. The build tool of our choice is checkstyle btw. :)
    – Thomas
    Jul 12 '11 at 12:46

It greatly helps to uniform the code in the company, and thanks to that you generally produce a more easily understandable and way more easily maintainable structure for your product.


Well, the advantages are the same as any code formatter, like standardization of the code, semantic between developers, etc. The only possible disadvantages I see is the lack of a human eye after the formatting, to add some exceptions, etc.
So I guess is better consider a IDE formatter instead of a check-in time formatter.


In my experience, it's a good thing. Without one, code compares often show a mess of whitespace formatting, and may hide actual code changes. In my experience, messing with someone's formatting isn't the sin it's made out to be, especially with the potential benefits of consistency across the team.

Not the answer you're looking for? Browse other questions tagged or ask your own question.