DevOps Zone is brought to you in partnership with:

Avi is a senior developer with a passion for Java technologies… http://www.aviyehuda.com/ Avi is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Best Code Convention Syndrome

10.16.2013
| 8365 views |
  • submit to reddit

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.

Published at DZone with permission of Avi Yehuda, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

José Casimiro replied on Wed, 2013/10/16 - 5:42am

For me the problem goes beyond the conventions of code.
The style of programming or developing habits also cause many problems, especially in new teams.
The size of the team increases the likelihood of conflicts.
I prefer to work with a team to five elements.

But in the end, programmers are human. Every human interaction always generates some conflict due to the personal interests of each being above the collective.

Mike P(Okidoky) replied on Wed, 2013/10/16 - 9:01pm

I think Allman style formatting is much cleaner, safer, and more efficient, than K&R style that's commonly used in Java.

Currenly, I get away with a blend, where I format "my files" using Allman, and honor "other people's files" using their style. But I would really like it if the whole world changes, sees the light, and accepts that Allman style is better enough that they will drop K&R and adopt Allman. Not going to happen.

The solution here is to use the editor's re-formatting feature. I use Eclipse mainly (and vim). I think Control-Shift-F (is it?) formats the current file. But instead of having one configured set of formatting rules, I want two sets, and then have one hot-key for each. Does anyone know of a plugin or script or otherwise it being supported as-is, in Eclipse?


Oleksandr Alesinskyy replied on Wed, 2013/10/23 - 8:15am in response to: Mike P(Okidoky)

where I format "my files" using Allman, and honor "other people's files" using their style

The only problem is that in a good team (in most cases) should not be any separation on "my files" and "other people's files"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.