Is coding style mostly for readability or are there other factors?

Question

I remember reading in Douglas Crockford's "Javascript the Good Parts" book that there is potential for error with blockless statements because of automatic semicolon insertion.

if (condition)
   foo = true;

vs

if (condition) 
{
   foo = true;
}

In the second the example it will work consistently, in the first example a semicolon will be automatically inserted by the interpreter and can lead to ambiguity in the code. As Douglas points out this is potentially bad and hard to debug, which I agree. But it got me thinking are there examples where coding "style" actually has syntax implications? In other words, examples where failing to follow a certain indentation or apparent style actually results in a bug or error. I suppose Python with its significant whitespace is an example, YML with its requirement for no tabs is another.

Feel free to respond in a wide variety of languages and idioms. I am curious to hear about the paradigm cases. In your answer I would like to know the WHAT and the WHY of the coding style or syntax behavior. I don't want to start any coding style flame wars, just matter of fact scenarios where the uninitiated would get tripped up.

Answer 1

In Python, the whitespace indentation, rather than curly braces or keywords, delimits the statement blocks. An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.

Answer 2

Javascript treats these two cases seperately. You have to use the first

return {
   // code
}

return 
{
   // code
}

If you do not the interpreter adds semi colons in the wrong places. I think it puts one after the condition. So the second would be read wrongly as.

return;
{
   // code
}

Which is not invalid syntax.

Answer 3

Whitespace is not significant in any of the C family of languages, except to separate certain language tokens. The layout of the source code has no effect on the executable produced by the compiler.

Answer 4

It depends on the language. In the curly family C/C++/Java/C#, whitespace is not the restriction as long as your braces are opened and closed properly.

In languages like VB where paired keywords are used, just because keywords delimit functions you can't have

Private Sub someFunction() End Sub

But in C, C++ and other curly languages, you can have

void someFunction() { }

In python, I guess its a completely different matter.

It all depends on the particular language. As per your specific example, I don't think there is a syntactical or semantic difference between the two.

Answer 5

In C++, there's a difference between

vector<pair<int,int>>

and

vector<pair<int,int> >

because >> is treated as a single token by the parser.

Answer 6

A coding style is not only for readability. There are some other factors like

• Avoid common language pitfalls (silent fails, exceptions while casting etc.)
• Ease of maintenance
• Increase the clarity of code (e.g. private functions always starting loweCase and public beeing PascalCase)
• Enforcing conventions (e.g. not using multiple inheritance or always inherit public in c++)

an example for ease of maintenacne is below:

if(x) return true;

vs.

if(x) 
{
   return true;
}

it is clear the second is easier to maintain, because i can simply go ahead and add a new line and add a call to bla() without having to add brackets before.

Answer 7

It is language dependant. For instance in Java

void someFunction() { }

and

void someFunction() { 
}

and

void someFunction() 
{ 
}

will have no implication whatsoever. However Sun has enlisted a list of coding conventions if you are interested you could read them here.

These are mainly for maintainability and readability of code but need not be strictly followed.

Answer 8

No one has mentioned it before, but one point of style is to write

if (NULL==p) // ...

instead of

if (p==NULL) // ...

The two are functionally equivalent so it's a matter of style. Many prefer the style at the top, because if you type "=" by mistake instead of "==", the first won't compile whereas the second will, and creates a bug that is hard to find (though some compilers now give you a warning for if (p=NULL)).

Answer 9

Every time I open a parentheses, brace, single or double quote I always close it and then go back to write the statement, condition, etc... This saves me from quite some possibly big mistakes!

Answer 10

The title wasn't specific to conditional blocks, so this came to mind:

I don't see it mentioned yet, but one thing to consider is how do you find things with simple tools (like grep and its inferior implementations from windowsland).

For example consider this (admittedly a bit contrived) example

class Foo
// vs.
class
Foo

You can find former with regex "class\s+Foo", but for latter you'll have to have a specialized tool that can parse C++/C#/java.

This applies also in C for function prototypes, some weird people prefer

void
bar (void)
// to 
void bar(void)

While you can generally assume that if in front of function name are some A-Z characters, then it's very likely definiton/declaration.

Actually when it comes to ifblocks, then placing the brace has very big impact on debugging code in Visual Studio 200x. When it steps into function/block, it will place text/execution line cursor on opening bracket. So if the bracket happens to be waaaaay on the right side, the code window has to scroll there and buggeritall stays there. Extremely annoying.