Best code convention syndrome

Developers often tend to think that one coding convention is better than another in terms of readability. Some people think that adding a break before the curly braces is more coherent. Some like camelCase, some hate it.
The fact of the matter is, there isn’t any proof that one convention gives better readability than another.

Now don’t misunderstand me, I am all for coding conventions, coding conventions are a good thing, but the holy wars for which convention is better seems redundant to me. If indeed one format is better than the other, it has a lot less affect on your performance than you would like to think.

The truth is that the convention you prefer gives you better performance simply because you are used to it.
The best format to use, the one that would give best results, is the one that you are most comfortable with, even if it is not the best one (if there is indeed a best one).

The way our brain works is it always searches for familiar structures to make it work less. When you read a piece of code, your mind finds templates which exists in your memory to ease the job of thinking (does this remind you of a certain design pattern? 🙂 ).

For some developers this code:

function doThisThing(PerssitedIdsArr){
  var i;
  for(i=0; i<PerssitedIdsArr.length; i++){
    console.log(PerssitedIdsArr[i]);
  }
};

would take a few milliseconds less to understand, than this code:

do_this_thing = function(perssited_ids_arr)
{
  for(var i in perssited_ids_arr)  
    console.log(perssited_ids_arr[i]);
};

For some, it would be the other way around.

That is why so often it happens that developers start a new job or start working on an existing product, and think that the formatting which the code was written in, is not as good as the one they are usually using. Even if these developers are sure that their format is better objectively, most chances that their preference is better to them simply because they are used to it.

Many times developers would try to insert their own formatting and even reformat existing code with the “better” convention. The reason to do that is probably not selfish, they truly believe that this format would be more useful for all the developers and to the company. The real truth is that there is a good chance this is doing more harm than good.

This is also the reason why many times you see a product written with different formats ,sometimes even in the same file. Different developers wrote it and each of them had good intentions in mind, and that is to use the best format for the job. However, as mentioned, choosing one convention over another is a lot less important than making sure all of the team is using the same format, a job which is sometimes not so easy in itself.

Therefore if a new developer joins a team which are already using unified coding conventions for their code, it would be much more effective to let the new developer get used to the exiting code than to make all the others learn the new conventions.
If the group doesn’t have unified coding conventions than the new developer may use his/her conventions. But if this developer wishes to reformat exiting code it should be done with a great care since it may cause unnecessary merging conflicts with changes from other developers, it would be better for this developer to try getting an agreement on unified coding conventions which will be known by everybody in the team.