I don't think the Sun Code Conventions are ambigious, I think they wanted to keep the spec from being too long and expect you to exert the brain power to infer the details where they are not explicit. Who really wants to read 200 pages on exact code conventsions? I know I think the 20 they already have are more than I care to read again.

After years of coding I still find #1 completely unreadable. For the life of me I can't understand why people use it. If you need your IDE to point out where your blocks start and stop, something's wrong

I never need my editor to line up the blocks... amazingly my eye can line up the indentations just fine.

Quote

if (isTrue()) { // do something}

See, the if lines up with the brace

If you really do work where the styles vary, just use Jalopy, the java code formatter. Once you set it up, you can easily convert back and forth between styles (and not just for braces, but for all the other bad habits people have). Pick a common style (recommend Sun's conventions) and have people convert back and forth as they check it out/back in from source control. It works great and also integrates into many IDEs

I used it to clean up 1950 classes which had this as the if-else indentation style! (Used the command line version and it only took a few mins )

Quote

if (test1) {

} else if (test2) {

} else if (test3) { }

That code was generated by an IDE of all things (VisualAge for java) and there was no way to turn it off (it's a really old version of VisualAge).

There are only 10 types of people, those who understand binary and those who don't!

If you think THAT wastes space, you should see how my friend codes.. He argues that you have to scroll vertically no matter what so he breaks lines all over the place "consistently" so you are reading vertically practically..

e.g. any function with more than one parameter has each parameter on a separate line, the close ); is on a line by itself. Function declarations are split with the return type on a line by itself, and the parameters on their own lines. These lines are split even if they can fit easily within a single line of < 80 columns. he says people have their editor windows at different widths etc, but everyone is used to vertical scrolling, long lines that don't fit completely on the display are always irritating, etc.. blah blah...

I think it is butt ugly and much harder to read .. but I draw the line at not aligning the braces... leaving the { dangling on the end of the line makes it harder to recognize blocks from single lines particularly when you have a blank line after the first line of the block.

I like #2, and is what I use at my job. As for wasted "space", folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine. Or get a used, cheap one from someone upgrading to dual LCD's or something. Just get one of those and maximize your IDE and any arguments about "wasting vertical space" should be alleviated. I've never "bought" the whole "wasted space" argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college). I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I'm just odd.

I like #2, and is what I use at my job. As for wasted "space", folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine. Or get a used, cheap one from someone upgrading to dual LCD's or something. Just get one of those and maximize your IDE and any arguments about "wasting vertical space" should be alleviated. I've never "bought" the whole "wasted space" argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college). I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I'm just odd.

I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I'm just odd.

Absolutely. The blocks stick out plain as day. With #1 if there's any amount of nesting of blocks I have to stop and follow it fairly carefully, especially if I didn't write the code. Most people who are fans of #1 are usually fans of no extra linefeeds whatsogoddamnever too!

But now that most IDEs can reformat code in seconds, it doesn't bother me so much.

Oh boys. Using 1 is much better you know, at least much better than read C++ code especially open source.Best is to have IDE that could reformat code to your style and then back to original. In most cases you are responsible for the class file and you do every modification yourself. [CODE]public void meth(){ somedeclaration; int c4=(int) log(c6); for(int c7=0;c7<12366;c7++){ callsomethingweird(c4); }}[/CODE]my programs look better after dissasambly, but I hardly do mistake. I lost most time becouse I didn't believe there wasn't mistake. And was lazy to use out.println();

come on people, #1 is the way to go....#2 reminds me of a double negative....the exact start of the function already lines up with the exact end, and doesnt this just make sense? i'm sure you all realize this but it's more symmetrical to have ONE start line and ONE end line.

Sorry, I'm bored; waiting for a server to crash, so I can view the logfiles (I've just turned full debugging on). So, with nothing better to do... (don't take this too seriously)

IIRC this has already been covered. Braces ARE NOTHIGN TO DO WITH FUNCTIONS (in the general case), they merely allow multi-line statements.

Hence, the "start line" as you put it is, in fact, the opening brace NOT the function.

Quote

symbols such as { && ||, etc really shouldnt start their own lines, just as the words "including", "and", and "or" do not properly begin sentences in English.

Grammatically speaking, they actually DO start their own lines, because they are phrase-starters, and we're talking about phrases, NOT sentences.

But because of early drop-out, you cannot tell at a glance down the LHS which lines will execute. This is important because speed-readers read in columns, and they have to read the LHS anyway to see the end-braces (irrespective of style).

Research into how musicians sight-read has concluded (rather unexcitingly ) that the main difference between "excellent" and "poor" sight-readers was that the really good ones scanned in an almost monotonic line across the page, NEVER going backwards. Novices darted forwards, backwards, etc, and just couldn't keep up with the music (which of course has to move forwards monotonically too).

The research was done using eye-tracking, and plotting graphs on the music of where the musician was looking over time. Interesting stuff .

The thing is the beginning of the line is not always equivalent to the beginning of a sentence, and there are other reason to but &&, || at the beginning of the line instead of the end.

Basically they can get 'lost' off the end of the line when you are reading code.. the end of the line is generally more jagged, and it could be of the screen entirely. Placing the && || at the beginning, nicely aligned shows clearly in a more localised spot how the conditions are logically evaluated.

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