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.

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.

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:

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

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

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.

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.publicintgetInt() {try {returnInteger.valueOf(this.value).intValue(); }

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.

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.publicintgetInt() {try {returnInteger.valueOf(this.value).intValue(); }

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

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.

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

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

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org