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.
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.
public class Foo { // CODE }You'll notice the keyword public is all the way to the left, as is the left and right brace.
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 ) ; } }
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.
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.
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.
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?
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
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.