Joshua Waring
|
 |
«
Posted
2012-11-06 07:35:22 » |
|
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); } |
|
The world is big, so learn it in small bytes.
|
|
|
Regenuluz
|
 |
«
Reply #1 - Posted
2012-11-06 08:01:16 » |
|
I use the compact version and I find it just as easy to read as the spaced out one. 
|
|
|
|
SwampChicken
|
 |
«
Reply #2 - Posted
2012-11-06 08:02:43 » |
|
I use the compacted version but with an indent of 2.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
princec
|
 |
«
Reply #3 - Posted
2012-11-06 09:48:09 » |
|
Compact, tabbed, 4-char width. Cas 
|
|
|
|
KittenKoder
|
 |
«
Reply #4 - Posted
2012-11-06 10:55:46 » |
|
Compact ... I'm a minimalist. I don't even comment ... much.
|
I am no one else.
|
|
|
Varkas
|
 |
«
Reply #5 - Posted
2012-11-06 11:35:51 » |
|
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
|
 |
«
Reply #6 - Posted
2012-11-06 11:39:29 » |
|
Compact, standard eclipse's setting.
|
|
|
|
DrHalfway
|
 |
«
Reply #7 - Posted
2012-11-06 11:40:43 » |
|
I use both styles...
Wait a minute... those examples are from my dead tutorial that no one likes!
|
|
|
|
Joshua Waring
|
 |
«
Reply #8 - Posted
2012-11-06 12:12:58 » |
|
 Hope you don't mind.
|
The world is big, so learn it in small bytes.
|
|
|
DrHalfway
|
 |
«
Reply #9 - Posted
2012-11-06 12:24:18 » |
|
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
|
 |
«
Reply #10 - Posted
2012-11-06 12:29:28 » |
|
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
|
 |
«
Reply #11 - Posted
2012-11-06 12:53:09 » |
|
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
|
 |
«
Reply #12 - Posted
2012-11-06 13:10:15 » |
|
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
|
 |
«
Reply #13 - Posted
2012-11-06 13:38:47 » |
|
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
|
 |
«
Reply #14 - Posted
2012-11-06 15:38:26 » |
|
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
|
 |
«
Reply #15 - Posted
2012-11-06 15:41:35 » |
|
@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
|
 |
«
Reply #16 - Posted
2012-11-06 22:56:11 » |
|
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
|
 |
«
Reply #17 - Posted
2012-11-06 23:04:10 » |
|
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.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
actual
|
 |
«
Reply #18 - Posted
2012-11-07 01:41:34 » |
|
@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
| 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
|
 |
«
Reply #19 - Posted
2012-11-07 01:56:56 » |
|
@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
| 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
|
 |
«
Reply #20 - Posted
2012-11-07 05:16:43 » |
|
Ahh that makes me cry. I use the new line for brackets like so 1 2 3 4
| void method(blah blah blah) { } |
And tab for indenting. I have no issues with the compact version and sometimes use it for some reason.
|
|
|
|
Nate
|
 |
«
Reply #21 - Posted
2012-11-07 05:25:56 » |
|
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
|
 |
«
Reply #22 - Posted
2012-11-21 21:59:09 » |
|
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
|
 |
«
Reply #23 - Posted
2012-11-21 23:08:08 » |
|
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
|
 |
«
Reply #24 - Posted
2012-11-22 00:00:03 » |
|
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.xmlThey 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.
|
"Experience is what you get when you did not get what you wanted"
|
|
|
ra4king
|
 |
«
Reply #25 - Posted
2012-11-22 05:05:14 » |
|
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) { initializeDeliciousPie(); if(coolnessLevel > 9000) eatPie(); else { System.out.println(hi); throwAwayPie(); } while(getValue() < 10) incremementValueForNoReason(); do { attemptSendingData(); } while(!isDataSent()); doSomethingInteresting(1, 2, "Wut?"); } |
|
|
|
|
sproingie
|
 |
«
Reply #26 - Posted
2012-11-22 06:22:51 » |
|
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
|
 |
«
Reply #27 - Posted
2012-11-22 06:43:53 » |
|
hehe I am using ____ from some class names mainly because...well the normal java way did not help the lengthyness.
|
|
|
|
Best Username Ever
|
 |
«
Reply #28 - Posted
2012-11-23 00:25:18 » |
|
And lastly: NEVER USE UNDERSCORE. It's ugly.  Heh. Good idea. What do you do for constants? ALL_CAPS_ARE_PRETTY_UGLY_TOO...
|
|
|
|
ra4king
|
 |
«
Reply #29 - Posted
2012-11-23 05:46:02 » |
|
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 
|
|
|
|
|