Its got to be number 2 
I really find number 1 to be confusing to read. I dont really care about saving vertical space I’ve got a scroll wheel on my mouse!
I think I probably prefer #2 because of my old Pascal days, and now I subconsciously read { as BEGIN, and } as END lol
swpalmer,
Your last post is EXACTLY the reason I have won the brace style argument at any company I have been at.
It breaks the symmetry. You can’t easily identify a block of code.
Between that, forcing no single-line unbraced ifs, fors, and whiles, I feel I have made a signifcant contribution to the coding style of various companies. ;D
Seriously, though, I think that any argument towards compressing code to “save space” is seriously pushing towards nonreadability. I prefer very open, very well spaced (I’m a maniac when it comes to this) source code that is easily navigable.
I use IDEA as my development environment, and there’s two things about it that totally make life simple for me. One, built in is the concept of code folding. I’m told that there are other IDEs that have this now also. You can selectively fold a block of code so that a little “+” sign in the left gutter appears, and you can unfold it if you wish. Second, I use a plug in called Tabifier, and yes, as I said I am a maniac when it comes to this. I align all my important declarations and definitions to a ridiculous nature:
boolean b = false;
int i = 3;
String name = 2;
Why? So I can read it!
[quote]come on people, #1 is the way to go…#2 reminds me of a double negative.
public void foo()
{
//blah
}
is readable, but the braces do not have to be lined up because in
public void foo(){
//blah
}
the exact start of the function already lines up with the exact end, and doesnt this just make sense? i’m sure you all realize this but it’s more symmetrical to have ONE start line and ONE end line.
symbols such as { && ||, etc really shouldnt start their own lines, just as the words “including”, “and”, and “or” do not properly begin sentences in English.
thats why I prefer
public void foo(args){
if(long boolean statement one &&
long boolean statement two){
}
else if(boolean){
}
}
over this monstrosity:
public void foo(args)
{
if(long boolean statement one
&& long boolean statement two)
{
}
else if(boolean)
{
}
}
[/quote]
Quiet! Nexus is one of the guys working on the project. 
What project?
Arg!!
This topic just never dies…
#2 !!! ALL THE WAY !!!
In the end, like someone previously mentioned,
its just personal preference…
Personally, I find #2 looks better…
and seems to make more sense if you look
at your code as a picture.
public void foo(args){
if(true){
}
else if(boolean){
}
}
public void foo(args)
{
if(true)
{
}
else if(boolean)
{
}
}
To me, its visually more balanced ,
Imagine rotating your code 90 degrees
counter clockwise, doesn’t #2 look
alot better then #1
Anyways, the above rambling is just
for rambling’s sake. I find it interesting
how many people have extremly strong
opinions on something relatively trivial.
Myself included.
You like the following ??
public static Object getObject(String param1,
String param2,
String param3,
String param4,
String param5)
{
}
(i mean, method params on different lines)
to be honest as long as you put in tabs/spaces before the code within the block, seeing where the block starts and ends is a matter of looking for the lines that start a few characters in from the rest of the block. Having said that, I use number 1
Endolf
#1 - but always with a space between the closing bracket and opening brace ie “public foo() {”
Saying that it doesn’t line up isn’t really true as tab indentation should be enough to be able to separate code blocks (certainly I find this so). I find the more traditional (for C programmers) #2 harder to read as it adds lines which are at the same tab depth.
While 19" monitors may be prevalent - not everyone has them and certainly I haven’t yet seen a laptop with a 19" LCD display. When it comes to printed technical documentation and books (or just plain printed out code) - the argument for #1 gets even stronger as #2 wastes page space and when you are looking at several small methods of only a few lines the wastage really stacks up. For small methods, i’m sure even staunch #2 supporters would agree that their style doesn’t improve readability.
One of my friends who used to use #1 has now decided that Java is slow and crap - and that C++ is what “real” programmers use - as protest he has switched his style from #1 to #2 (for all his code, C++ or not) which I find amusing.
To summarise - I think people should use #1 because it’s easier on the eyes and more environmentally friendly.
Will.
[quote] When it comes to printed technical documentation and books (or just plain printed out code) - the argument for #1 gets even stronger as #2 wastes page space and when you are looking at several small methods of only a few lines the wastage really stacks up. For small methods, i’m sure even staunch #2 supporters would agree that their style doesn’t improve readability.
[/quote]
My initial reaction to any methods that are that small (and, incidentally, to any classes that are over 1000 lines of code) is to question the original design. A one-line method, for instance, is usually a method that is either unnecessary or is boiler-plate code. Anything less than about 5 lines I’m inclined to check whether the design is actually correct.
I’m a big fan of never doing boilerplate code - if you take some time to learn parsers and compiler development, you can nearly always write a code-generator that generates your boiler code quicker than you could type that code in the first place, and you save yourself weeks of time when it comes to maintenance.
My Software Eng. lecturer used to wax lyrical about a study (or several) which measured the probability of a given person introducing a bug into code they produced. The biggest single factors in increasing bugginess were boredom and not understanding what you were doing (no suprise there!). So I avoid boilerplate code like the plague (anyway we’ve got OO now; we should be doing new boilers, not more boilerplates ). I don’t think the study(s) looked into the effects of sleep deprivation… :).
I couldn’t agree less about printing code in a book. What kind of rubbish book is it if it goes around quoting tiny methods all the time? (IMHO your example implies lots of these, not just one or two - or else you’re unlikely to really care about the difference).
If you’ve printed souce-code to review or debug it, then from experience I’d usually think you’re better off with it taking up more pages. Usually people only do this because they’re having trouble doing in on the PC - it seems there are very few people around these days who still write / debug source code on paper as opposed to in an IDE. If you’re having trouble, then code that takes up more space makes it easier to spot the mistake(s), rather than have it hide in lots of text. Perhaps it’s similar to the optical/mental illusions that hide extra words in a paragraph, and ask you “what is wrong with this sentence”, e.g.:
The little
red dog and
and the brown
dog went home.
Such tricks are harder to notice the more dense the text. Expanding it out prevents you from skim-reading it, usually causing you to read more of the words and hence find the problem.
Shrug. IMHO.
[quote]My initial reaction to any methods that are that small (and, incidentally, to any classes that are over 1000 lines of code) is to question the original design. A one-line method, for instance, is usually a method that is either unnecessary or is boiler-plate code. Anything less than about 5 lines I’m inclined to check whether the design is actually correct.
[/quote]
I agree with a lot of what you said… but I’m not sure about this. In fact OO and Java seem to promote many smaller methods than fewer big ones.
There is of course the boilerplate getter/setters which are supposedly preferred over direct access to member variables.
Of course here I am with the “main” class of my current project coming in at over 5600 lines … I need to do some refactoring, but I actually don’t think it is as bad as it sounds.
The argument about small methods and OO design aside - my comment also applies to if statements, while loops etc…
ie. if you use #2 for all braces (I was under the impression this was an “all or nothing” debate). And if you have a book with a lot of if statements and while loops etc then it will start to add up.
I say this because I have several books which use #1, and some more extreme cases where they purposely condense code lines so that it fits in a smaller space (by placing several statements on one line etc). I am not 100% in agreeable with that practice however I still think that using #1 is better as it cuts lines yet doesn’t decrease redability.
From my personal perspective - source code that goes over the page is a lot harder to read. It means that you can’t sit back and look at the code in once piece you have to keep flipping. (Appendixes aside).
Many books give short code snippits which may contain if statements etc. Having superfluous new lines does IMHO bloat it out and isn’t preferable in most situations (especially printed ones).
Hope that is clarifying,
Will.
[quote]What project?
[/quote]
The game my friends and I are working on.