Ahh that makes me cry.
I use the new line for brackets like so
void method(blah blah blah)
{
//more blah
}
And tab for indenting. I have no issues with the compact version and sometimes use it for some reason.
Forgot to mention, the Eclipse formatter has special tags to enable/disable. I rename the tags to @off and @on. Sometimes the formatter needs to be off entirely.
I will make my case for the “non-compact” method: It’s easier to read. Books have indents at the beginning of paragraphs. Not because it looks better, but for purely practical reasons. It helps to mark transitions between two sections of texts and makes it easier to find a specific location while scanning a page vertically. Source code is a different format, but the ability to scan and visually identify structures is even more important.
[tr][td]1 =========================================== 2 =######################################==== 3 =#========================================= 4 ===###############========================= 5 ===#################======================= 6 ===##############========================== 7 =========================================== 8 ===##############========================== 9 ===#======================================= 10 =====##########============================ 11 =====######================================ 12 =====#########============================= 13 =====#===================================== 14 ========#######============================ 15 ========#######============================ 16 =====#===================================== 17 =========================================== 18 =====######================================ 19 =====#######=============================== 20 ===#======================================= 21 =#========================================= 22 ===========================================[/td][td]1 =========================================== 2 =######################################==== 3 ===###############========================= 4 ===#################======================= 5 ===##############========================== 6 =========================================== 7 ===##############========================== 8 =====##########============================ 9 =====######================================ 10 =====#########============================= 11 ========#######============================ 12 ========#######============================ 13 =====#===================================== 14 =========================================== 15 =====######================================ 16 =====#######=============================== 17 ===#======================================= 18 =#========================================= 19 ============================================[/td][/tr]
The use of highly visible empty space is much easier to see when scrolling through source code at 90% the speed of light very fast. The indents do most of the work to make code easier to read on the macro level, but the nearly blank lines still make a pretty big impact. It’s easier to identify chunks of code while looking at only the first few rows on the left*. It’s easier to match the starting and ending lines together. (I have a hard time finding the matching “{” for the one on line 17 on the right. Is it line 13? 10? 7? 2? It’s easier to match it with line 7 if I tilt my head 30 degrees to the left, but that doesn’t feel very ergonomic.) On a micro level it’s also slightly easier to read. The blank line is a nice visual cue. It’s not as important in that case, but in my opinion the marginal improvement in readability (“legibility”?) makes it worth it over the even more marginal cost of a few extra bytes. (Is it just me, or does anyone else think space-{-enter is harder to type than enter-{-enter on a US Qwerty keyboard? … And don’t some IDEs work if you just type { or enter?) The fact that it’s easier to read while scrolling quickly makes up for the fact that it takes more vertical screen space.
- I use 2 spaces for block-level indents and one space indents on line continuations. I don’t know why anyone would use more than 3 spaces… One is two few to work with the bracket system I use, but more than three seems wasteful. It’s actually a lot easier to identify which rows have an even or odd number of spaces than I would have ever guessed before I discovered the 2-1 space indent system, so it makes multiple line statements look much cleaner. Unlike the crazy things IDEs and text editors use for defaults.
Does my ascii-art drawing of source code help anyone see the difference, or do I only imagine this difference after making reading/writing the separate line style habitual?
I’m quite easy about formatting; as long as it’s consistent throughout the project.
Personally I prefer compact formatting, so opening brackets at the end of the line. And line breaks after at least 160 or 200 characters.
I do however like to prevent code blocks without brackets, so no
if (something)
doStuff();
but
if (something) {
doStuff();
}
I think it’s (both) even more readable than having everything on one line, as it makes the condition more obvious.
I don’t care at all about tabs or spaces; if you use a formatter there’s really no point to that discussion imho.
I do however use @formatter:on/off tags sometimes, for example to keep constant array tables readable or to prevent empty lines between members where they’re not necessary.
As much as I like to write things compactly, I do like Eclipse to insert the ‘final’ keyword for me (I still think final should have been default, with instead a ‘mutable’ keyword).
As a last preference (which is somehow hard to sell to fellow java developers so I never force it anywhere): I think
do_something_important();
is much more readable than
doSomethingImportant();
Although I did use the eclipse defaults for a long time, I am now using the libgdx eclipse formatter settings
They are a little more compact than default eclipse.
However, to be honest over the years. I have never really cared too much one way or the other. I just go with the flow of whatever the requirements are. Often for class different teachers have different desires. Otherwise whne I have no standards(free fun stuff) I tend to be a little messy the first pass thru and clean it up later. (I don’t forget!) Though default eclipse or whatever works.
I absolutely hate using any IDE that doesn’t have an autoformatter built in by default. I know like visual studio, you can get 3rd party ones, I just don’t understand why some IDEs dont have at least a crappy subpar one for at the very least fixing indents and such.
I’m extremely strict on myself when it comes to formatting:
public void myMethod(String hi, int coolnessLevel) {
// <-- only tabs, tab = 4 spaces
initializeDeliciousPie();
if(coolnessLevel > 9000) //no space before the first parenthesis
eatPie(); //if body is only 1 line, *don't* use brackets
else {
System.out.println(hi);
throwAwayPie();
}
// blank lines *must* also have indents
while(getValue() < 10)
incremementValueForNoReason();
do { //do-while is the only exception to the bracket rule. *must* use brackets even for 1-line body, or else it looks ugly
attemptSendingData();
} while(!isDataSent());
doSomethingInteresting(1, 2, "Wut?"); // 1 space between each argument
// And lastly: NEVER USE UNDERSCORE. It's ugly. :)
}
Indenting blank lines is something eclipse does but IDEA doesn’t. Considering it amounts to “trailing whitespace on a line”, I’m inclined to say eclipse’s behavior is wrong. Regardless, it’s really annoying when one IDE adds trailing space or another strips it out and creates spurious diffs. I wish mercurial could be made to ignore diffs of nothing but whitespace the way diff itself can. Maybe it’s doable with a hook, but I’m not sure how a hook can be told that the diff is whitespace.
I try not to mix bracket-less and bracketized blocks like that. I also try to avoid do-while entirely. I also never use tabs for indent because they’ll always be wrong somewhere I view them whether it’s a terminal or a browser or whatever.
hehe I am using ____ from some class names mainly because…well the normal java way did not help the lengthyness.
Heh. Good idea. What do you do for constants? ALL_CAPS_ARE_PRETTY_UGLY_TOO…
Oh…right that’s the only exception. I’ve only used underscore once for multiword constants 
I have to have every single command in a method on the same line like so:
public void method(){
if (thing == otherthing){
System.out.println("Yay!");
System.out.println("Cool!");
//more code
//blah blah blah
}else {
System.out.println("No!!");
System.out.println("The world is about to die!!");
//more code
//blah blah blah
}
}
This excepts comments (which I don’t really use anyway ;D )
I can’t stand it being like this:
public void method(){
if (thing == otherthing){
System.out.println("Yay!");
System.out.println("Cool!");
//more code
//blah blah blah
}else {
System.out.println("No!!");
System.out.println("The world is about to die!!");
//more code
//blah blah blah
}
}
(I also like to have my } s indented (especially }) ;D)
Yeah that’s called proper formatting. But “} else {”?!? No. NO. It has to be “}\n else {”
for me it’s
if (blah) {
goAndEhhNaahForgetIt();
} else {
whatElse("?");
}
Heathen! Blasphemy! 
Well, I like things to be as consistent as possible, so I’d go with matheus23’s way.
No “//if body is only 1 line, don’t use brackets” because imho that serves no purpose other than making the syntax less consistent/simple.
But hey, at the end of the day formatting rules are quite unimportant when it comes to code readability.
Clean, well written, easy to understand and consistent code goes way beyond things like formatting rules.
As a simple example, if you look up “double checked locking” for singletons; there’s no way any formatting can make that sort of gross uglyness even remotely readable (or good practice for that matter). If a singleton for some reason really makes sense (it usually doesn’t), I’d use an enum. Or even just write static methods.
cuddled-else is hardly “blasphemy”, it’s very traditional. However, I’ve gotten to like “compact control readability style” which uncuddles the else from the closing brace of the if, making all the control structures line up at the left column of the code.
As for double-checked locking, it works perfectly fine as of 1.5 … but yeah it’s still ugly. I always preferred the “initialization on demand holder idiom” anyway when I’m not using a proper DI container.
Cuddly code is nice, and wants to be your friend.
Personally I just went with the Sun Java standards way back whenever they were defined and now all it is is a matter of brain-pattern-matching for me. If something doesn’t immediately instantly match the pattern I am expecting just by literally glancing at it - totally subconsciously - it looks wrong and my OCD forces me to fix it. Or rather Eclipse’s autoformatter. This is all part of programming; seeing recognisable patterns in the shape of code at a glance helps us know that it is written correctly, in our own minds; a missing bracket for example, and the indentation goes mental. What is especially annoying in this day and age is that code is still basically uniquely text-file based and designed to work with version control systems that work on the concept of “lines” rather than ASTs.
In a sensible world, all code would look exactly as we want it to look while we’re editing it, in much the same way as the syntax colouring in my editor is mine and mine alone. Code would always be autoformatted, and autoformatted exactly in the way we like, with a learning system that learns formats from us. And then when it went into version control it would be compared semantically rather than purely syntactically; or at the very least, compared simply with all whitespace stripped.
Cas
If you have to describe something about coding as “traditional,” then… 
publicclassLikeThis?
Not to mention that for some languages, whitespace is significant, meaning such a VCS would be useless for those languages.
Really slick idea though. Eclipse already does a “Java structure compare” out of the box when committing to CVS (which for some reason my eyes always glaze right over), so it does seem others have attempted to bolt on such ideas to existing version control, in one form or another.
Yup - so “all it needs” is a version control system designed to work after whitespace is removed. I have a funny feeling it might actually be a lot better than the crap we deal with right now.
Cas