Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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
  ignore  |  Print  
  What's your preference is spacing  (Read 5537 times)
0 Members and 1 Guest are viewing this topic.
Offline Joshua Waring

Senior Member


Medals: 4
Projects: 2



« Posted 2012-11-06 08: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.
Offline Regenuluz
« Reply #1 - Posted 2012-11-06 09:01:16 »

I use the compact version and I find it just as easy to read as the spaced out one. Smiley
Offline SwampChicken
« Reply #2 - Posted 2012-11-06 09:02:43 »

I use the compacted version but with an indent of 2.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2012-11-06 10:48:09 »

Compact, tabbed, 4-char width.

Cas Smiley

Offline KittenKoder

Senior Member


Medals: 7



« Reply #4 - Posted 2012-11-06 11:55:46 »

Compact ... I'm a minimalist. I don't even comment ... much.

I am no one else.
Offline Varkas
« Reply #5 - Posted 2012-11-06 12: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.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline ReBirth
« Reply #6 - Posted 2012-11-06 12:39:29 »

Compact, standard eclipse's setting.

Offline DrHalfway
« Reply #7 - Posted 2012-11-06 12:40:43 »

I use both styles...


Wait a minute... those examples are from my dead tutorial that no one likes!

Offline Joshua Waring

Senior Member


Medals: 4
Projects: 2



« Reply #8 - Posted 2012-11-06 13:12:58 »

 Grin
Hope you don't mind.

The world is big, so learn it in small bytes.
Offline DrHalfway
« Reply #9 - Posted 2012-11-06 13:24:18 »

Of course I don't mind... Its why I took the time to write the thing!  Grin

Always makes me happy when someone gets anything out of whatever I write  Grin

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Damocles
« Reply #10 - Posted 2012-11-06 13: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...)

Offline Regenuluz
« Reply #11 - Posted 2012-11-06 13: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. Smiley
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #12 - Posted 2012-11-06 14: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(',');

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline actual

JGO Coder


Medals: 23



« Reply #13 - Posted 2012-11-06 14: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...
Offline sproingie

JGO Kernel


Medals: 201



« Reply #14 - Posted 2012-11-06 16: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."
Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #15 - Posted 2012-11-06 16: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 Smiley
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.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #16 - Posted 2012-11-06 23: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. Wink 130 columns, 3 space tabs, braces on same line. You can get them here:
https://github.com/libgdx/libgdx/blob/master/eclipse-formatter.xml

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 742
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2012-11-07 00: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
Offline actual

JGO Coder


Medals: 23



« Reply #18 - Posted 2012-11-07 02: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 Smiley
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.
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.
Offline ra4king

JGO Kernel


Medals: 336
Projects: 2
Exp: 5 years


I'm the King!


« Reply #19 - Posted 2012-11-07 02: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 Smiley
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.
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

Offline StumpyStrust
« Reply #20 - Posted 2012-11-07 06: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)
{
                  //more blah
}


And tab for indenting. I have no issues with the compact version and sometimes use it for some reason.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #21 - Posted 2012-11-07 06: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.

Offline Best Username Ever

Junior Member





« Reply #22 - Posted 2012-11-21 22: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?
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #23 - Posted 2012-11-22 00: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();

Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #24 - Posted 2012-11-22 01: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.xml

They 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"
Offline ra4king

JGO Kernel


Medals: 336
Projects: 2
Exp: 5 years


I'm the King!


« Reply #25 - Posted 2012-11-22 06: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) {
    // <-- only tabs, tab = 4 spaces
   
    initializeDeliciousPie();
   
    if(coolnessLevel > 9000) //no space before the first parenthesis
       eatPie(); //if body is only 1 line, *don't* use brackets
   else {
        System.out.println(hi);
        throwAwayPie();
    }
   
    // blank lines *must* also have indents
   
    while(getValue() < 10)
        incremementValueForNoReason();
   
    do { //do-while is the only exception to the bracket rule. *must* use brackets even for 1-line body, or else it looks ugly
       attemptSendingData();
    } while(!isDataSent());
   
    doSomethingInteresting(1, 2, "Wut?"); // 1 space between each argument
   
    // And lastly: NEVER USE UNDERSCORE. It's ugly. :)
}

Offline sproingie

JGO Kernel


Medals: 201



« Reply #26 - Posted 2012-11-22 07: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.
Offline StumpyStrust
« Reply #27 - Posted 2012-11-22 07:43:53 »

hehe I am using ____ from some class names mainly because...well the normal java way did not help the lengthyness.

Offline Best Username Ever

Junior Member





« Reply #28 - Posted 2012-11-23 01:25:18 »

And lastly: NEVER USE UNDERSCORE. It's ugly. Smiley

Heh. Good idea. What do you do for constants? ALL_CAPS_ARE_PRETTY_UGLY_TOO...
Offline ra4king

JGO Kernel


Medals: 336
Projects: 2
Exp: 5 years


I'm the King!


« Reply #29 - Posted 2012-11-23 06:46:02 »

And lastly: NEVER USE UNDERSCORE. It's ugly. Smiley

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 Smiley

Pages: [1] 2
  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.

pw (12 views)
2014-07-24 01:59:36

Riven (10 views)
2014-07-23 21:16:32

Riven (11 views)
2014-07-23 21:07:15

Riven (12 views)
2014-07-23 20:56:16

ctomni231 (42 views)
2014-07-18 06:55:21

Zero Volt (38 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (34 views)
2014-07-16 23:30:00

Cero (50 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!