Advantages and Disadvantages of Forced Code Reformat

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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...

  if(
      (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.

Answer 5

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.

Answer 6

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.

Answer 7

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. :)

Answer 8

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.

Answer 9

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.