Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Brace styles  (Read 10414 times)
0 Members and 1 Guest are viewing this topic.
Offline leknor

Junior Member




ROCK!!!


« Reply #30 - Posted 2003-06-30 18:47:43 »

Quote
But just to argue for arguing's sake, This is only for class and interface declaration.
I read that to mean "declarations in a class or an interface" which expands the scope from just the class or interface line to the whole body of class/interface.

Quote
one could argue that the rules do not specificly apply to scope blocks.
True, but you can infer. Eg: an if statement looks like:
Quote
if (condition) {
   statements;
}
so if you remove the "if (contition) " you have:
Quote
{
   statements;
}

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

Senior Newbie




I love YaBB 1G - SP1!


« Reply #31 - Posted 2003-06-30 22:45:53 »

Being an old unix hacker, I use #1 but follow the conventions of the project.

BTW: checkstyle (http://checkstyle.sf.net) includes a brace checker which
is rather useful.  There will also be an indention checker in the 3.2
release (which is also good for more religious wars).
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #32 - Posted 2003-07-14 00:31:57 »

I use #2.

Partly because that's what I "grew up with" as a programmer, and partly because it feels kinda naughty to go against Sun.
It makes me feel kinda like a rebel, instead of an underpaid code monkey boy.  Grin

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tortoise

Junior Member




<3 Shmups


« Reply #33 - Posted 2003-07-14 00:44:59 »

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 Smiley

But there are even worse styles out there, like the dreaded

void
someFunction() {
}

If memory serves isn't that also gnu? or even weirder

public
void someFunction() {
}
Offline Kevdog

Junior Member





« Reply #34 - Posted 2003-07-14 21:21:14 »

Ooo..... can't let this one slip by:

I use #1 and so do most (all?) of the people I work with.  #2 wastes lines, especially on nested ifs!
Quote

if (test1)
{
   if (test2)
   {
       //do something
   } else
   {
       //do something else
   }
} else
{
   // do a third thing
}


Looks sooo much better as:
Quote

if (test1) {
   if (test2) {
       //do something
   } else {
       //do something else
   }
} else {
   // do a third thing
}


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 Smiley

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 Smiley

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 Smiley )
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!
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #35 - Posted 2003-07-15 00:26:00 »

Hehe, this is fun...

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

Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #36 - Posted 2003-07-15 11:54:34 »

Quote

I use #1 and so do most (all?) of the people I work with.  #2 wastes lines, especially on nested ifs!


Heh, I'm even worse than your example. I put the else on its own line.

1  
2  
3  
}
else
{

Play Minecraft!
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #37 - Posted 2003-07-15 12:10:21 »

Anyway, the argument that should win this for us #2's pretty quick: (haha, right)

Everyone probably agrees that a free standing block should look like this:

1  
2  
3  
4  
5  
6  
7  
foo();
bar();
{
    Cat tempCat = CatFactory.getDefault().newCat();
    foo(tempCat, Cat.BITE_EXPENSIVE_CORD);
}
foo();


ie the { and the } on their own lines, and the contents of the block pulled in n spaces.

And even though you're not supposed to use them, everyone probably agrees that an "unblocked" if should look like this:

1  
2  
3  
4  
if (weather.isNice())
   setState(State.HOT | State.HEAVY);
else
   setState(new EmotionState("Awww.."));


ie the statement after the if is on a separate line, and is pulled in n spaces.

Well, the killer argument is that a block is really a multi-statement/multi-line statement, and by putting the { on the same line as the if, you're basically doing

1  
if (evidence.isGettingWeak()) startWrappingUp(); else keepPushing();


The fact that the block contains newlines so it looks better is just a coincidence. Advocates of #1 would probably consider the following perfectly fine:

1  
if (notSureWhatToDo) {} else {}


..

Actually, I think this all means that the GNU style is the "best" way.. Hm.
Damn.

Play Minecraft!
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #38 - Posted 2003-07-15 14:21:08 »

Your unblocked is wrong. It should look like this:

1  
2  
if (weather.isNice()) setState(State.HOT | State.HEAVY);
else setState(new EmotionState("Awww.."));


If you want new lines, it won't kill you to use braces:

1  
2  
3  
4  
5  
6  
7  
8  
if (weather.isNice())
{
   setState(State.HOT | State.HEAVY);
}
else
{
   setState(new EmotionState("Awww.."));
}


Java Game Console Project
Last Journal Entry: 12/17/04
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #39 - Posted 2003-07-15 14:27:13 »

Agreed, it won't kill me, but the argument won't be as amusing.

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nickdotjava

Junior Member




I have fallen to the dark side. &nbsp;I'm using DX9


« Reply #40 - Posted 2003-07-15 14:37:18 »

Quote


Heh, I'm even worse than your example. I put the else on its own line.

1  
2  
3  
}
else
{


I do the same thing with the else.  Every brace gets its own line.   Grin

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
Offline EgonOlsen
« Reply #41 - Posted 2003-07-16 19:53:23 »

Quote
everyone probably agrees that an "unblocked" if should look like this:
No, i agree that everyone who uses "unblocked" ifs should be shot anyway... ;D

Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #42 - Posted 2003-07-16 20:47:07 »

*quickly cleans up code*

Play Minecraft!
Offline nech_neb

Junior Member




Java for LIFE !!!


« Reply #43 - Posted 2003-07-18 16:36:08 »

Quote

No, i agree that everyone who uses "unblocked" ifs should be shot anyway... ;D


That's some harsh words over personal preference...

I personally feel unblocked one liner ifs makes
things more readable.

Feel free to flame me now...
;D
Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #44 - Posted 2003-07-18 16:58:13 »

I said it before in this thread, and I'll say it again. I really don't think it matters one way or another, as long as you are consistent and all who contibute code use the same style.

Don't send a man to do a monkey's work.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #45 - Posted 2003-07-18 17:03:13 »

YOU FOOL!


Grin

Actual code from my friends C++ project.. this is how he writes it, I have not added any line breaks:

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  
26  
27  
28  
29  
30  
31  
// removed beginning of function...
     hRes = m_pDevice->QueryInterface(
                                                __uuidof( IMyGraphics ),
                                                (void**)&pGFX
                                                );
      if( !SUCCEEDED( hRes ) )
            throw _com_error( hRes );

      // <removed real comment>
     m_pGFX = pGFX;
      hRes = pGFX->Release();

      if( !SUCCEEDED( hRes ) )
            throw _com_error( hRes );
}

void
MyDevice::FreeResources(
      void
      )
{
}

void
MyDevice::CollectInfo(
      void
      )
{
      m_DeviceInfo = m_pDevice->QueryInformation();
      m_StreamInfo = m_pStream->QueryInformation();
}


oh yeah - if he had a multi-line 'if' it would have the braces lined up - the one part where I agree with him Smiley
Could you force yourself to conform to this style? - I can't.

Offline tom
« Reply #46 - Posted 2003-07-19 14:03:04 »

I started out using #2, and for a long time I detested reading #1 code. But I switched to #1 because most of my coworkers and the java stander used it. Now I don't realy have a personal preferance.

It's a question about habit, not what is best.

Offline PlanetMongo

Senior Newbie




Follow the yellow line. &nbsp;Don't EAT the yellow line


« Reply #47 - Posted 2003-07-23 19:25:21 »

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.

If you were me, you'd be good lookin - six string samurai
Offline nickdotjava

Junior Member




I have fallen to the dark side. &nbsp;I'm using DX9


« Reply #48 - Posted 2003-07-23 20:43:36 »

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


Mongo, I completely agree with you.  #1 sucks.   Tongue

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
Offline tortoise

Junior Member




<3 Shmups


« Reply #49 - Posted 2003-07-23 20:53:58 »

Quote
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! Smiley

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

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #50 - Posted 2003-07-25 19:37:52 »

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();
Offline NexusOne

Junior Member




Java games rock!


« Reply #51 - Posted 2003-08-13 04:50:17 »

come on people, #1 is the way to go....#2 reminds me of a double negative.

public void foo()
{
    //blah
}

is readable, but the braces do not have to be lined up because in

public void foo(){
    //blah
}

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.


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.

thats why I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }
    else if(boolean){
    }
}

over this monstrosity:

public void foo(args)
{
    if(long boolean statement one
    &&  long boolean statement two)
    {
    }
    else if(boolean)
    {
    }
}
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #52 - Posted 2003-08-13 05:03:13 »

Which brings us round to another pathetically silly point:

spaces and lining things up

This above:

1  
2  
3  
4  
5  
6  
7  
public void foo(args){ 
     if(long boolean statement one &&
     long boolean statement two){
     }
     else if(boolean){
     }
}


should be written

1  
2  
3  
4  
5  
6  
public void foo(args) {
      if (long boolean statement one &&
          long boolean statement two) {
      } else if (boolean) {
      }
}


And when I say should I mean, thats the way I do it Wink

Kev

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #53 - Posted 2003-08-13 05:24:08 »

Quote
And when I say should I mean, thats the way I do it

Me too, that ought to be enough people to make it a fact, ehh?

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #54 - Posted 2003-08-13 09:32:53 »

Oh, no.  When wrapping a single statement over multiple lines, you have to indent it twice.  Or even better, avoid it!  Chances are you probably should break that statement up into smaller chunks anyway.

And the boolean condition definitely goes on the second line, to improve readability.  You don't say "chips and, peas" rather than "chips, and peas" do you? Grin

Hellomynameis Charlie Dobbie.
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #55 - Posted 2003-08-13 09:43:07 »

I wouldn't put a comma in either  Grin

Kev

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #56 - Posted 2003-08-13 11:49:03 »

Roll Eyes

No, neither would I - it's only there for emphasis... Tongue

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #57 - Posted 2003-08-13 13:43:16 »

Quote
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... Wink (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.

Quote

I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }


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

malloc will be first against the wall when the revolution comes...
Offline GergisKhan

Junior Member




&quot;C8 H10 N4 O2&quot;


« Reply #58 - Posted 2003-08-13 14:02:09 »

Aha.  So that's why I always botched my sight reading.  Then again, sight reading in competition is bogus, as far as I can see.

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #59 - Posted 2003-08-13 20:58:10 »

Quote
i'm sure you all realize this but it's more symmetrical to have ONE start line and ONE end line.

No, visually you break the symmetry of the braces - THEY wrap the block, not the method declaration before them

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.

thats why I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }
    else if(boolean){
    }
}

over this monstrosity:

public void foo(args)
{
    if(long boolean statement one
    &&  long boolean statement two)
    {
    }
    else if(boolean)
    {
    }
}


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.

e.g.
1  
2  
3  
4  
5  
6  
     if( long boolean statement one
      && short bool
      || long boolean statement two
       )
     {
     }

Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (10 views)
2014-09-21 23:33:17

BurntPizza (28 views)
2014-09-21 02:42:18

BurntPizza (18 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (29 views)
2014-09-19 03:14:18

Dwinin (46 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!