One of the biggest challenges for geek programmers when starting a new job or project is getting used to a new of source code formatting. Each and every one of us is used to our own way of formatting source code and vehemently defend it while denouncing every other way as “unreadable” and “doesn’t make any sense.”

When beginning a function implementation, do you put the curly bracket on the same line or in the next? Do you use else if or elseif? The compiler (or interpreter) really doesn’t care, why should your teammates do?

A VCS can be extended to allow each individual programmer to choose their own source code format. On commit to the repository, the VCS will save the source code in its most condensed form by removing all extraneous whitespace that the compiler tends to ignore, for one. On checkout, the code will be formatted according to the choice of the programmer and everyone will be happy.

Of course, this requires the VCS to be aware of the language in use. If the VCS replaces else if with elif in a .c file or removes all whitespace from a .py file the code won’t compile. Another problem is that auto-formatters won’t allow deviations from the format. A programmer might choose to refrain from using the standard format on one piece of code to increase its readability. For example, by adding line breaks in the parameters list when calling a function with a lot of parameters:

...
boolean status = getStatusByForm(
  status,
  "Hard coded string",
  variable1,
  variable2,
  complexType1.getValue1(),
  complexType2.getValue2(),
  SomeEnum.ValueOne,
  SomeOtherEnum.ValueTwo,
  variable1,
  variable2,
  ...
  variableN);
...

Auto-formatters can be told to either format all function calls like the above, or to add line breaks after a certain number of characters was reached:

...
boolean status = getStatusByForm(status, "Hard coded string", variable1,
  variable2, complexType1.getValue1(), complexType2.getValue2(),
  SomeEnum.ValueOne, SomeOtherEnum.ValueTwo, variable1, variable2, ..., ...,
  ..., ..., ..., variableN);
...

Another example is formatting a long list of variable initializers in a table:

void example() {
  int              status              = 0x00;
  String           myName              = "Daniel";
  String           nameOfFavoritePet   = "Kangaroo";
  FavoritePetType  enumFavoritePetType = FavoritePetType.Marsupial;
  ...
}

which is lost in almost all auto-formatters:

void example() {
  int status = 0x00;
  String myName = "Daniel";
  String nameOfFavoritePet = "Kangaroo";
  FavoritePetType enumFavoritePetType = FavoritePetType.Marsupial;
  ...
}

This proposed VCS extension doesn’t free programmers from following the team’s standard practice in everything, but it can liberate them from the most vexing and meaningless argument: Tabs, or 4 spaces?