What's your preference is spacing

[Joshua Waring]

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:

1   2   3   4   5   6

public Operator()    {             state = new NullState();    }

example of compact:

1   2   3   4

public int compute(int number1, int number2) {       return state.operate(number1, number2);    }

[Regenuluz]

I use the compact version and I find it just as easy to read as the spaced out one.

[SwampChicken]

I use the compacted version but with an indent of 2.

Games published by our own members! Check 'em out!

[princec]

Compact, tabbed, 4-char width.

Cas

[KittenKoder]

Compact ... I'm a minimalist. I don't even comment ... much.

[Varkas]

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.

[ReBirth]

Compact, standard eclipse's setting.

[DrHalfway]

I use both styles...


Wait a minute... those examples are from my dead tutorial that no one likes!

[Joshua Waring]

 
Hope you don't mind.

[DrHalfway]

Of course I don't mind... Its why I took the time to write the thing! 

Always makes me happy when someone gets anything out of whatever I write 

Games published by our own members! Check 'em out!

[Damocles]

strictly like that:
I want to know where the brackets belong to, haing the same indent.

1   2   3   4   5   6   7   8   9

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...)

[Regenuluz]

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.

1   2   3

if(var == true) {     System.out.println("Yay"); }

If you just go straight down from the if, you'll encounter the matching bracket.

1   2   3   4

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.

[Abuse]

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:

1   2   3   4   5   6   7

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:

1   2

sb.append(callStart.toString(outputFormat)).append(',').append(dataDuration).append(',').append(callDuration).append(',').append(destination)             .append(',').append(area).append(',').append(charge).append(',').append(balance).append(',');

[actual]

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:

1   2   3   4   5   6   7   8   9   10   11   12

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...

[sproingie]

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.

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."

[matheus23]

@actual:

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.

[Nate]

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:
https://github.com/libgdx/libgdx/blob/master/eclipse-formatter.xml

[Riven]

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.

Until then, I use:

1   2   3   4   5   6   7

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.

[actual]

@actual:

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 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. 

1   2   3   4   5   6   7

// 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.

[ra4king]

@actual:

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 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. 

1   2   3   4   5   6   7

// 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

[StumpyStrust]

Ahh that makes me cry.

I use the new line for brackets like so

1   2   3   4

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.

[Nate]

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.

[Best Username Ever]

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.

1  =========================================== 2  =######################################==== 3  =#========================================= 4  ===###############========================= 5  ===#################======================= 6  ===##############========================== 7  =========================================== 8  ===##############========================== 9  ===#======================================= 10 =====##########============================ 11 =====######================================ 12 =====#########============================= 13 =====#===================================== 14 ========#######============================ 15 ========#######============================ 16 =====#===================================== 17 =========================================== 18 =====######================================ 19 =====#######=============================== 20 ===#======================================= 21 =#========================================= 22 ===========================================

1  =========================================== 2  =######################################==== 3  ===###############========================= 4  ===#################======================= 5  ===##############========================== 6  =========================================== 7  ===##############========================== 8  =====##########============================ 9  =====######================================ 10 =====#########============================= 11 ========#######============================ 12 ========#######============================ 13 =====#===================================== 14 =========================================== 15 =====######================================ 16 =====#######=============================== 17 ===#======================================= 18 =#========================================= 19 ============================================

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?

[erikd]

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

1   2

if (something)   doStuff();

but

1   2   3

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

1	do_something_important();

is much more readable than

1	doSomethingImportant();

[namrog84]

Although I did use the eclipse defaults for a long time, I am now using the libgdx eclipse formatter settings

https://github.com/libgdx/libgdx/blob/master/eclipse-formatter.xml

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.

[ra4king]

I'm extremely strict on myself when it comes to formatting:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25

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. :) }

[sproingie]

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.

[StumpyStrust]

hehe I am using ____ from some class names mainly because...well the normal java way did not help the lengthyness.

[Best Username Ever]

And lastly: NEVER USE UNDERSCORE. It's ugly.

Heh. Good idea. What do you do for constants? ALL_CAPS_ARE_PRETTY_UGLY_TOO...

[ra4king]

And lastly: NEVER USE UNDERSCORE. It's ugly.

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