This post will be about code formatting and maybe some reasons for the formatting decisions developers make.  Actual code that got me thinking used an if statement, but below I used 2 for loops because its easier to spot what can go wrong:

for (int i = 0; i < 10; i ++)
    for (int j = 0; j < 10; j ++)
          Method1();
    Method2();
Method3();

First question: Do you know how many times are the methods being called?  If you copy/paste the code and run it you will see that Method1 is called 100 times and after that Method2 and Method3 are executed. Looks good.

Now, imagine you are looking at that code someone else wrote and try to answer this question: Are you 100% sure that Method2() should be executed only once? Maybe the method should be executed only 10 times? Or maybe 100 times? It is a tough question and you probably can't answer it without asking the person who wrote the code some questions. I bet you there would be no ambiguity if you used parenthesis like this:

for (int i = 0; i < 10; i ++)
{
    for (int j = 0; j < 10; j ++)
    {
          Method1();
    }
    Method2();
}
Method3();

I remember when I was an intern in Dublin I wrote similar code (it was also a for loop) and I didn't use the parenthesis. Senior developer who was doing a review asked me the same question. Your code will be more readable if you use parenthesis in this case. Besides, you could also avoid some bugs.

I am not sure what the reason is, for not using parenthesis but a coworker told me about the another formatting 'issue' and the reason for it.

public void MyMethod (int arg1, string arg2, bool arg3) {
      DoSomethingHere ();
}

Notice in above code the parenthesis is inline with the method declaration. And apparently the reason for that was that back in the days the monitors didn't have high resolutions and writing the parenthesis in the same line saved you one line on the monitor screen.

I am guessing the reason people are still writing the code this way is only a habit and nothing else. I know everybody has his own style of coding and code formatting and this doesn't mean your code is bad.

Let me end this post with a short story that could apply to the above text. I read this in Steve Maguire's book Debugging the Development Process. The story goes like this:

"A boy asked his mother how come she cuts off the edges of a pot roast when putting it into the pot. Mother told him that that's how her mother taught her to do. So, boy went to his grandmother and he got the same answer. Then he went to his grand-grandmother and ask her the same question. The answer was: Well, back then my pot was to small and the meat didn't fit inside."

Old habits never die.