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?

A while back I was working on a proof-of-concept for an Android game when the following code found its way to the codebase:

It’s readable, but it might take a moment to realize what goes where. What if that method could look like this?

While this example is relatively easy to read and understand, the following example is less so:

And with math styling:

Suddenly it seems familiar, right?

This feature can be easily implemented in existing IDEs as a plugin. Programmers will write the expression and select an option in the IDE that will convert the expression to a stylized display – behind the scenes a LaTeX code will be generated and rendered. The IDE will then display the stylized expression and the compiler will get the equivalent expression in a form that it can understand. Programmers will have the ability to edit the actual LaTeX code so that they can style it however they choose, and the feature will make sure that the expression is always in sync with its LaTeX presentation.

Of course, we also need to think about programmers that don’t use an IDE that supports this feature – this can be made to work by injecting the LaTeX code inside comments that surround the expression. An example of how this will look in the source file (which still remains in text format) as well as in an IDE that doesn’t support this feature:

Why the duplication? There are many ways to format the same equation in LaTeX, and if we auto-generate the LaTeX every time the file loads in the IDE it might not be formatted as the programmer wanted it. Granted, this is not the most readable or elegant solution. I’m sure someone can think of an implementation that’s more readable and more stable from a technical standpoint.

This feature idea opens up new possibilities for embedding more intuitive formats of code inside the plain-text. Perform operations on a matrix, replace method calls with equivalent mathematic notations (such as replacing Math.abs(x) with |x|), etc. Any ideas of your own?