Incremental Java
Style: Indenting if, if-else, and method bodies

Style

Most people unfamiliar with programming think of programming as number crunching. When beginners hear about style, they might wonder what style has to do with programming. Isn't programming about solving a problem?

That's certainly true. But it's more than that. Programs are often evolving, changing. New features are added. Functionality is changing. Different people work on the programs.

There's a need for people to read programs and understand it, and one way to do this is to write programs with good style. Good style helps you understand a program by removing distractions.

Identifier Style

We've talked about writing Java-style identifiers. Here's what we said: Following these rules about Java identifiers makes code look aesthetically pleasing, but also makes it easier for people to write code. If you use underscores sometimes, and not other times, it makes it hard for others using your code to remember which convention you used.

Indentation

Perhaps the most important style rule you can learn is to indent properly. The compiler cares nothing about indentation, but if you indent well, you make your code so much easier to read, which means you'll make it easier to debug.

Indentation allows the physical layout (how the code appears on the screen) to match the logical layout (what the code means).

Let's look at some indentation.

Class Definitions

A class definition should start in the leftmost column. You should use an open and close brace all the way to the left.
public class Foo
{
  // CODE
}
You'll notice the keyword public is all the way to the left, as is the left and right brace.

Methods and Instance Variables

The rule of thumb is that anything inside a block (an open/close brace pair) should be indented. Usually, a good text editor or IDE has support for indentation. I'm using 3 spaces of indentation. Some prefer more.
public class Foo
{
   private int count ;
   private boolean isValid ;

   public static void main( String [] args )
   {
      // CODE
   }
}
Notice how the instance variables and the methods are all lined up 3 spaces in. That's because they are within a block, and everything is indented in 3 spaces in the block.

As you can see, main() also has its own block (i.e., the method body). So anything in main() should be indented 3 more spaces in (for a total of 6 spaces).

public class Foo
{
   private int count ;
   private boolean isValid ;

   public static void main( String [] args )
   {
      // Indented 6 spaces in
      int val = 3, x = 2 ;
      System.out.println( "val is " + val ) ;
   }
}

if statements

The rule of thumb is that each time you are in a block you indent 3 more spaces in. Each time you're done with a block, you indent 3 spaces back out.

Let's see an example with an if statement that has a block.

public class Foo
{
   private int count ;
   private boolean isValid ;

   public static void main( String [] args )
   {
      // Indented 6 spaces in
      int val = 3, x = 2 ;
      if ( val == x )
      {
         // Indented 6 spaces in
         x++ ;
         System.out.println( "Incrementing x" ) ;
      }
      System.out.println( "val is " + val ) ;
   }
}
Notice that the open and close braces always lines up. Thus, the open and close brace for main() lines up with the 'p' in public (of public static void main).

The open/close brace in the if body lines up with the letter 'i' of the if statement.

Look at the last println() (which prints "val is.."). It's not in the if body so it is not indented in 9 spaces. It's indented to the same position as the if statement itself.

if-else statements

Here's an example of if-else.
public class Foo
{
   private int count ;
   private boolean isValid ;

   public static void main( String [] args )
   {
      // Indented 6 spaces in
      int val = 3, x = 2 ;
      if ( val == x )
      {
         x++ ;
         System.out.println( "Incrementing x" ) ;
      }
      else
         x-- ;
      System.out.println( "val is " + val ) ;
   }
}
Notice that keyword else lines up with if. The else body also lines up with the if body. That way we can easily see which else matches with which if.

Parameter and Argument Lists

Here are examples of how I write method calls with arguments:
foo.bar() ;
foo.bar( 10 ) ;
foo.bar( 10, 20 ) ;
foo.bar( 10, x + y ) ;
foo.bar( 10, x + ( y - z ) ) ;
I'm assuming bar() is overloaded.

On the first line, I show an example where the argument list is empty. I write an open and close parentheses.

On the second line, I have a single argument. I add one space after the open parenthesis and one before the close parenthesis. I'll admit this is uncommon, but I like the way it looks.

On the third line, I have two arguments. As on the second line, I have the one space after the open parenthesis and one space before the close parenthesis. I also put one space after the comma, separating the arguments. Putting a single space after the comma is a widely accepted style.

On the fourth line, I have an expression for the second argument. I use a space before and after the + operator. Some people don't like doing this because it adds too much space.

Some use no space at all, and write:

foo.bar(10, x+y) ;
The only space is after the comma. This works too. What isn't so good is using spaces like:
foo.bar(10, x+ y) ;
There's a space after the + but not before it. This is usually a sign of sloppiness. Such a programmer will have this space sometimes, and not have it at other times. Be consistent with your style.

The fifth line has a more complex expression for the second argument. It looks like:x + ( y - z ). It uses all the rules from before. Add a space before and after operators. Add a space after left parenthesis and before right parenthesis.

Parameter Lists

Parameter lists should follow similar rules. Fortunately, parameters are simpler than arguments. They only contain a type and a parameter name, and can't be expressions.

Some examples:

public int computeCost( int cost, int tax ) ;
You can think of a parameter list as a simpler example of an argument list.

Semicolons

I usually put one space before a semicolon. This is very unusual. However, I do it to make the semicolons easier to see. I find that if you put the semicolon immediately after a close parenthesis, it's hard to see.

Consider:

    System.out.println( "Hello, World!" );
and
    System.out.println( "Hello, World!" )
and
    System.out.println( "Hello, World!" ) ;
Did you see the missing semicolon in one of the examples above?

Why You Should Learn Style Now

Having taught beginners how to program for several years, I've discovered that some students refuse to learn style. To their way of thinking, their first priority is to learn how to program, and style gets in their way. They find it tedious to remember style rules. Even as you stress how important it is, they think they know better with only a few months of experience.

Not surprisingly, many of these beginners never become very good programmers.

Why? Ask yourself, which is harder: learning these style rules, or learning to program? Most would say style rules are easier to learn. If you can't learn style rules, then how do you expect to learn how to program?

The main reason to learn style is to make your program easier to understand. The second reason is that code written with good style simply looks more professional.

People always say that you should spell check your resume. To have typographic errors shows you don't care. Now this may be completely false. What does correct spelling have to do with anything? Yet, people do care, so you are also forced to care. The same applies to programming

It's Religious

Some people love their style. A lot. They hate other styles. They wince when they see braces a certain way, or spacing done a certain way, even if these alternative styles are just as valid.

I've presented a style I like, and suggest you use it. But don't believe it's the best style. It's just one person's opinion. You may decide, with more experience, to change your style, because you like some other way better. That's fine.

You may even be told that there is a standard style that a company wants any code written to follow. So follow it. Style is important, but don't get attached to one style or another. You should be flexible and realize that style is just a matter of opinion.

You pick a style, and stick to it, as much as is needed.