I was wondering which type of spacing of code is preferred? I write compact but find it easier to understand it once spaced out.
What’s your preference
example of spaced:
public Operator()
{
state = new NullState();
}
example of compact:
public int compute(int number1, int number2) {
return state.operate(number1, number2);
}
I use the compact version and I find it just as easy to read as the spaced out one. 
I use the compacted version but with an indent of 2.
Compact, tabbed, 4-char width.
Cas
Compact … I’m a minimalist. I don’t even comment … much.
My brain needs less information density, so I like the version with braces on separate lines. Usually I use a tab size of 4. I wouldn’t use empty lines in such a small method, though, but they are good to group code blocks in longer methods.
Compact, standard eclipse’s setting.
I use both styles…
Wait a minute… those examples are from my dead tutorial that no one likes!
;D
Hope you don’t mind.
Of course I don’t mind… Its why I took the time to write the thing! ;D
Always makes me happy when someone gets anything out of whatever I write ;D
strictly like that:
I want to know where the brackets belong to, haing the same indent.
public Operator()
{
state = new NullState();
if(duck==donald)
{
donald=donaldduck;
bla=blub;
}
}
In that compact code, they loose their meaning in structuring the source visually.
This style probably comes from the 70s when Monitors had expensive pixels and thus a low resolution.
But its easy in Eclipse to setup all that in the code formatter.
(Even the Java API Source has a mix of both…)
Ugh, I’d hate to read code like that, really. For me it’s quite easy to see where what belongs to, as long as it’s indented.
if(var == true) {
System.out.println("Yay");
}
If you just go straight down from the if, you’ll encounter the matching bracket.
if(var == true)
{
System.out.println("Yay");
}
That’s just as easy, but when you indent the brackets, it starts to have a weird readability, imo.
My preference: Ctrl+Shift+f
Though I wish formatters would detect uses of the fluent interface pattern, as I prefer to see method chaining broken 1 per line (or some other constant, if logical), rather than after an arbitrary number of chained invocations determined by the line width.
e.g.
this:
sb.append(callStart.toString(outputFormat)).append(',')
.append(dataDuration).append(',')
.append(callDuration).append(',')
.append(destination).append(',')
.append(area).append(',')
.append(charge).append(',')
.append(balance).append(',');
not this:
sb.append(callStart.toString(outputFormat)).append(',').append(dataDuration).append(',').append(callDuration).append(',').append(destination)
.append(',').append(area).append(',').append(charge).append(',').append(balance).append(',');
I prefer the “compact” version (I’ve heard these referred to as Egyptian brackets). The open bracket on its own line makes sense, but it’s always looked strange to me, so I never use it. If you are indenting properly, I don’t see that you really lose anything.
When I was getting into LISP I actually did the following for a little while:
public void printItems(String[] list) {
int nonNullCount = 0;
for (int i=0; i < list.length; i++) {
if (list[i] == null) {
System.out.println("<null>"); }
else {
nonNullCount++;
System.out.println(nonNullCount+". "+list[i]); }}}
…because…you know…LISP…I guess…
Tell the formatter to preserve linebreaks and you should be all set. It would be pretty neat though to be able to use type information to specify formatting overrides, i.e. “apply these settings when the value of the expression matches this class pattern.”
Thats not bad at all. In LISP…
But in LISP everything is more bracket-based than in Java. Then it makes sense, you know
In java it is “if ()” THEN “{ }”, in lisp it’s "(if " tocheck " " statementtrue " " statementfalse “)”… where it is also better to write the brackets like that.
I hit source format about every 3rd keystroke. I often don’t type spaces or newlines and let the formatter put them in. I sometimes use // at the end of a line to force the formatter to line break at a sensible spot. This is better than preserving newlines, which would make formatting less consistent. I also force my formatter settings on everyone, because they are the best. 
130 columns, 3 space tabs, braces on same line. You can get them here:
Until then, I use:
sb.append(callStart.toString(outputFormat)).append(',') //
.append(dataDuration).append(',') //
.append(callDuration).append(',') //
.append(destination).append(',') //
.append(area).append(',') //
.append(charge).append(',') //
.append(balance).append(',');
to tell the formatter to bugger off.
I am working on a small project and after this thread I decided to do it in my pseudo lispy style with the closing brackets all on the ending line.
// Take the string member field value and return it as an integer if you can. Otherwise throw an exception.
public int getInt() {
try {
return Integer.valueOf(this.value).intValue(); }
catch (Exception error) {
throw new UnsupportedOperationException("Value: "+value+" cannot be interpreted as an integer."); }}
It’s not as weird as I remember it being and I actually find it kind of pleasing aesthetically. Because both the opening and closing brackets are all at the ends of lines, by focusing on the beginnings of lines, gives it an almost pythonic look. It is also more compact vertically which is nice.
The main con is that it ss different, so if you are working on a team it may put people off, but if you are friendless a lone wolf like me, it doesn’t matter. The other is that you have to make sure you are consistent in your indenting because you are going to rely on it more.
O______O You must be mentally insane… that made my eyes bleed T___T