What Religion Are You?

General Discussions
#1

So I was once told that there is something that is religious for coders. Something that some do one way and others another. Something that for some can not be changed.

What is it?

The curly brace/bracket.


public void method(args....){    //<----- on the same line as the method

}

for(int j = 0; j <= i; j++){        //<------- same line as the loop

}

//The other way

public void method(args....)
{                                        //<------ After the method

}

for(int j = 0; j <= i; j++)
{                                        //<------- after the loop

}

Which religion are you? Before? or after?

I like after…more white space means easier for me to read.

#2

I converted from

for(...)
{

}

to

for(...) {

}

about a year ago, due to having to code extensively in Javascript.

It’s madness. I know.

#3

Before! Always before!!!

#4

I’m totally fickle. Some constructs on same line, other after and my rules are fluid depending on my mood and the overall look.

#5

I’ve always used the Sun convention because it makes for slightly more compact code and vertical space is always at a premium. The more I can squeeze onto the screen at a time the better. Also all the example code and the default formatter in IDEs all use the Sun conventions.

Don’t be telling me to break my methods into smaller chunks now ::slight_smile:

Cas :slight_smile:

#6

I’m the first type of guy too :slight_smile: Just looks better, imo :stuck_out_tongue:

#7

It’s like brushing teeth or using the mouse with the other hand.
I’ve always wanted to try using brackets on new line.
I tried it for some time, really wanted it to work out.
But in the end I went completely mad and switched back.

However, brackets on new line is really the best choice from an objective point of view, in my opinion, as it is more consistent and separate code from signature, giving a better view of the program structure.
Currently, I will on rare occasions, if argument list is very long or lots of exceptions are being declared to be thrown, switch to bracket on a new line.

It does really seem like a religious question. Interestingly, some “atheists” have removed the brackets from their language entirely. However, it does seem to bring new problems and well, I’ve become religious I guess XD

  • Scarzzurs
#8

I switched too (only my change was a few years ago) - not because of any tool but just to comply. When everyone around you does it differently, it doesn’t really pay to pigheadedly keep doing it the other way. Also I kept having to reconfigure source formatters.

I used to prefer the “bracket under the code” way because I reasoned that with proper indenting it made it only too clear which two brackets make a pair. But now that I use the other way the argument has become quite feeble even to myself; the closing bracket shows which statement that it belongs too. Same difference really, but more compact.

#9

It’s a shame that in this day and age auto-formatted source code editors (and concurrent source version control systems) have not become the standard. It should simply not matter where the whitespace is. It should look exactly like you like it to look, whoever wrote it.

Cas :slight_smile:

#10

@princec: Fair point. However most attempts at doing something like that I’ve seen has other downsides.
For example Maple makes it very unintuitive to edit the otherwise beautifully formatted math expressions.
Sometimes pressing the left arrow 3 or more times are required for moving one math character XD

  • Scarzzurs
#11

Seems like it’s settled. Boring.

}
else {

or

} else {

?

#12

If I’m editing someone else’s code, I follow their style.
If it’s mine then it’s usually ‘before’.

#13

Always } else [if] {

GFA Basic had autoformatted editing back in the late 80s on the Atari ST, with 3 different presentation styles.

Cas :slight_smile:

#14

Back in the days of pre-history when I was an employee I had CVS set-up to auto-convert to a standard format prior for repo compares and storage it would auto-change to the local person’s preference when pulling updates. I’d assume that some newer VC would allow this.

#15

I always


if (){

}else if(){

}else{
}
#16

Problem is that source code is pure text file, formatted using spaces, tabs, newlines etc.

Perhaps source code requires its own standard file format, whereas display of the code can be personalized.

And I prefer

if() {
}
#17

Always this.


if ()
{
     bla
}
else if()
{
     bla
}
else
{
     bla
}

Everthing else, especially standard java code convention, looks horrible to me

#18

Sun’s style when writing Java, K&R style when writing C.

At work, some folks take the “curly brace on a separate line” to what I believe to be extremes, leaving you with code like this:


try
{
   doSomething();
   x = getFoo();
}
catch (IOException e)
{
   handleError(e);
   logIt(e);
}
finally
{
   closeStreams();
}
#19

As long as it’s consistent I don’t really care. If it’s my own code I use the standard Java convention.

#20

I follow the “Clean Code” principals.

If it’s easy to read, then well, write like that. :point:

And fact is, new lines, curly braces, are just semantics that can clutter readability.

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882