How I Learned to Stop Worrying and Love the Coding Conventions
Can you spot the difference between the following two code snippets?
Exhibit #1:
public class MyClass
{
public int MyFunc(int x, int y)
{
return x + y;
}
}
Exhibit #2:
public class MyClass{
public int MyFunc(int x, int y){
return x + y;
}
}
If you have some programming experience you might recognize the two styles. One of which common in your projects and the other looks strange and might even cause you a slight discomfort or bad feeling at the pit of your stomach. Some software developers have been arguing about which is better for as long as I can remember and to tell the truth I was one of them until recently.
I work mostly in C# and the majority of projects/demos/tutorials out there use the first convention. I used to argue that it’s better because it makes the code more readable and besides that’s the Visual Studio default and if it’s good enough for Microsoft it’s good enough for me. Then I got to my current employer where the official coding standard defines option number 2 as well as other conventions and it was hard. Each time I glanced at my code I had the urge to re-format, it made me feel “dirty”. After a while I got used to the new curly brackets location but it still felt wrong to me. One of my responsibilities is to make sure that all of the teams projects follows the official company’s coding specifications some of which I don’t fully agree with.
I’m a fan of this developer’s life podcast and yesterday I heard the latest show Obsession
where Scott and Rob talk to several developers about their obsessions
and than it hit me – the feeling I have whenever I see code that
formatted “wrong” is my little OCD (obsessive compulsive disorder), it’s
one of the obsessions I picked up on the way, I need to code to be
“right”, similar behavior can be found when developers argue what is
better – camel-case or Pascal-case, spaces or tabs, VB.NET or C# and so
on. Many of these arguments are valid but sometimes we just miss the
point, just because we feel good/bad with something doesn’t mean that
it’s right it just mean we’re more comfortable with it and that’s ok.
As for coding standards there is a valid reason they’re in place – we want all of the company’s source code to follow the same rules. An important goal – even at the price of making you feel good about how the code looks.
One final note – this can only go so far, if the rules make the code less readable and the developers less effective – you should make an effort to change them.
Happy coding…
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





