Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (488)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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 10250 times)
0 Members and 1 Guest are viewing this topic.
Offline kemalenver

Senior Newbie




null pointer exception


« Reply #60 - Posted 2003-08-13 21:41:33 »

Its got to be number 2 Smiley  I really find number 1 to be confusing to read.  I dont really care about saving vertical space I've got a scroll wheel on my mouse!

I think I probably prefer #2 because of my old Pascal days, and now I subconsciously read { as BEGIN,  and  } as END lol
Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #61 - Posted 2003-08-14 00:42:44 »

swpalmer,

Your last post is EXACTLY the reason I have won the brace style argument at any company I have been at.

It breaks the symmetry.  You can't easily identify a block of code.

Between that, forcing no single-line unbraced ifs, fors, and whiles, I feel I have made a signifcant contribution to the coding style of various companies.  Grin

Seriously, though, I think that any argument towards compressing code to "save space" is seriously pushing towards nonreadability.  I prefer very open, very well spaced (I'm a maniac when it comes to this) source code that is easily navigable.

I use IDEA as my development environment, and there's two things about it that totally make life simple for me.  One, built in is the concept of code folding.  I'm told that there are other IDEs that have this now also.  You can selectively fold a block of code so that a little "+" sign in the left gutter appears, and you can unfold it if you wish.  Second, I use a plug in called Tabifier, and yes, as I said I am a maniac when it comes to this.  I align all my important declarations and definitions to a ridiculous nature:

1  
2  
3  
boolean b    = false;
int     i    = 3;
String  name = 2;

Why?  So I can read it!

gK

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

Junior Member




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


« Reply #62 - Posted 2003-08-19 02:51:31 »

Quote
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)
    {
    }
}



Quiet!  Nexus is one of the guys working on the project.   :P

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #63 - Posted 2003-08-19 03:03:16 »

What project?

Offline nech_neb

Junior Member




Java for LIFE !!!


« Reply #64 - Posted 2003-08-19 18:45:27 »

Arg!!
This topic just never dies....

#2 !!! ALL THE WAY !!!
In the end, like someone previously mentioned,
its just personal preference....

Personally, I find #2 looks better....
and seems to make more sense if you look
at your code as a picture.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
public void foo(args){ 
     if(true){
     }
     else if(boolean){
     }
}
 
public void foo(args)
{
     if(true)
     {
     }
     else if(boolean)
     {
     }
}


To me, its visually more balanced ,
Imagine rotating your code 90 degrees
counter clockwise, doesn't #2 look
alot better then #1 ^_^

Anyways, the above rambling is just
for rambling's sake. I find it interesting
how many people have extremly strong
opinions on something relatively trivial.
Myself included.

clo
Guest
« Reply #65 - Posted 2003-08-28 06:43:16 »

You like the following ??
1  
2  
3  
4  
5  
6  
7  
8  
public static Object getObject(String param1,     
                               String param2,
                               String param3,
                               String param4,
                               String param5)
{

}


(i mean, method params on different lines)
Smiley
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #66 - Posted 2003-08-28 09:15:29 »

to be honest as long as you put in tabs/spaces before the code within the block, seeing where the block starts and ends is a matter of looking for the lines that start a few characters in from the rest of the block. Having said that, I use number 1 Smiley

Endolf

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #67 - Posted 2003-09-02 00:46:12 »

#1 - but always with a space between the closing bracket and opening brace ie "public foo() {"

Saying that it doesn't line up isn't really true as tab indentation should be enough to be able to separate code blocks (certainly I find this so).  I find the more traditional (for C programmers) #2 harder to read as it adds lines which are at the same tab depth.

While 19" monitors may be prevalent - not everyone has them and certainly I haven’t yet seen a laptop with a 19" LCD display.  When it comes to printed technical documentation and books (or just plain printed out code) - the argument for #1 gets even stronger as #2 wastes page space and when you are looking at several small methods of only a few lines the wastage really stacks up.  For small methods, i'm sure even staunch #2 supporters would agree that their style doesn't improve readability.

One of my friends who used to use #1 has now decided that Java is slow and crap - and that C++ is what "real" programmers use  - as protest he has switched his style from #1 to #2 (for all his code, C++ or not) which I find amusing.

To summarise - I think people should use #1 because it's easier on the eyes and more environmentally friendly.

Will.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #68 - Posted 2003-09-02 06:45:50 »

Quote
When it comes to printed technical documentation and books (or just plain printed out code) - the argument for #1 gets even stronger as #2 wastes page space and when you are looking at several small methods of only a few lines the wastage really stacks up.  For small methods, i'm sure even staunch #2 supporters would agree that their style doesn't improve readability.


My initial reaction to any methods that are that small (and, incidentally, to any classes that are over 1000 lines of code) is to question the original design. A one-line method, for instance, is usually a method that is either unnecessary or is boiler-plate code. Anything less than about 5 lines I'm inclined to check whether the design is actually correct.

I'm a big fan of never doing boilerplate code - if you take some time to learn parsers and compiler development, you can nearly always write a code-generator that generates your boiler code quicker than you could type that code in the first place, and you save yourself weeks of time when it comes to maintenance.

My Software Eng. lecturer used to wax lyrical about a study (or several) which measured the probability of a given person introducing a bug into code they produced. The biggest single factors in increasing bugginess were boredom and not understanding what you were doing (no suprise there!). So I avoid boilerplate code like the plague (anyway we've got OO now; we should be doing new boilers, not more boilerplates Smiley ). I don't think the study(s) looked into the effects of sleep deprivation... Smiley.

I couldn't agree less about printing code in a book. What kind of rubbish book is it if it goes around quoting tiny methods all the time? (IMHO your example implies lots of these, not just one or two - or else you're unlikely to really care about the difference).

If you've printed souce-code to review or debug it, then from experience I'd usually think you're better off with it taking up more pages. Usually people only do this because they're having trouble doing in on the PC - it seems there are very few people around these days who still write / debug source code on paper as opposed to in an IDE. If you're having trouble, then code that takes up more space makes it easier to spot the mistake(s), rather than have it hide in lots of text. Perhaps it's similar to the optical/mental illusions that hide extra words in a paragraph, and ask you "what is wrong with this sentence", e.g.:

The little
red dog and
and the brown
dog went home.

Such tricks are harder to notice the more dense the text. Expanding it out prevents you from skim-reading it, usually causing you to read more of the words and hence find the problem.

Shrug. IMHO.

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

JGO Coder




Where's the Kaboom?


« Reply #69 - Posted 2003-09-04 00:29:55 »

Quote
My initial reaction to any methods that are that small (and, incidentally, to any classes that are over 1000 lines of code) is to question the original design. A one-line method, for instance, is usually a method that is either unnecessary or is boiler-plate code. Anything less than about 5 lines I'm inclined to check whether the design is actually correct.


I agree with a lot of what you said.. but I'm not sure about this.  In fact OO and Java seem to promote many smaller methods than fewer big ones.
There is of course the boilerplate getter/setters which are supposedly preferred over direct access to member variables.

Of course here I am with the "main" class of my current project coming in at over 5600 lines Smiley ... I need to do some refactoring, but I actually don't think it is as bad as it sounds.

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

JGO Coder


Projects: 2


Fire at will


« Reply #70 - Posted 2003-09-04 05:07:26 »

The argument about small methods and OO design aside - my comment also applies to if statements, while loops etc...

ie. if you use #2 for all braces (I was under the impression this was an "all or nothing" debate). And if you have a book with a lot of if statements and while loops etc then it will start to add up.

I say this because I have several books which use #1, and some more extreme cases where they purposely condense code lines so that it fits in a smaller space (by placing several statements on one line etc).  I am not 100% in agreeable with that practice however I still think that using #1 is better as it cuts lines yet doesn't decrease redability.  

From my personal perspective - source code that goes over the page is a lot harder to read.  It means that you can't sit back and look at the code in once piece you have to keep flipping.  (Appendixes aside).

Many books give short code snippits which may contain if statements etc.  Having superfluous new lines does IMHO bloat it out and isn't preferable in most situations (especially printed ones).

Hope that is clarifying,

Will.

Offline nickdotjava

Junior Member




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


« Reply #71 - Posted 2003-09-09 13:32:52 »

Quote
What project?

The game my friends and I are working on.

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
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.

TehJavaDev (17 views)
2014-08-28 18:26:30

CopyableCougar4 (26 views)
2014-08-22 19:31:30

atombrot (39 views)
2014-08-19 09:29:53

Tekkerue (36 views)
2014-08-16 06:45:27

Tekkerue (33 views)
2014-08-16 06:22:17

Tekkerue (22 views)
2014-08-16 06:20:21

Tekkerue (33 views)
2014-08-16 06:12:11

Rayexar (68 views)
2014-08-11 02:49:23

BurntPizza (45 views)
2014-08-09 21:09:32

BurntPizza (36 views)
2014-08-08 02:01: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!