Page 334 - Introduction to Programming with Java: A Problem Solving Approach

300 Chapter 8 Software Engineering Blank Lines
In general, use blank lines to separate logical chunks of code. In Figure 8.1’s StudentDriver class, note the blank lines:
• Between the prologue section and the class definition. • Right after a method’s local variable declarations.
It’s not shown in the Student program, but for long methods, it’s appropriate to insert blank lines between logically separate chunks of code within the method. Also, when a comment line appears within the body of the code, it’s nice to have white space above that comment to make it more visible.
Meaningful Names
Use meaningful names for your classes and variables. For example, Student is a good name for the class in Figures 8.2a and 8.2b because the class models a student. Similarly, setName would be a good name for a mutator method that sets a student’s first and last name instance variables, and getLast would be a good name for an accessor method that returns the last name.
Braces and Indentations
As shown in Figure 8.1 and Figures 8.2a and 8.2b, place opening braces ({) immediately below the first let-
ter of the preceding line. Indent everything that’s logically inside the brace. When you’re done with a block
(that is, when you’re ready for the closing brace), “outdent” so the opening and closing braces for a particular
block are aligned. By following this indent-outdent scheme, you’ll always align opening and closing brace
partners in the same column. For example, note how the Student class’s opening and closing braces are
Apago PDF Enhancer
both in the same column.
Our recommendation on where to put the opening brace ({) is different from Sun’s recommendation,
which is that the opening brace be at the end of the previous line, like this:
public void setName(String first, String last) {
}
this.first = first;
this.last = last;
This is one of the few places where our recommendation differs from Sun’s recommendation. Many pro- grammers follow the recommendation we prefer, because it provides better visual bracketing of the block of code that the braces define. However, placing the opening brace at the end of the previous line makes the code a little tighter, and if you or your teacher or your boss wants the opening brace at the end of the previ- ous line, you have our blessing to follow that convention.
Be consistent with your indentations. Any indentation width between two and five is acceptable as long as you’re consistent throughout your program. We use two spaces in the book because book page widths are less than computer screen widths, and we don’t want to run out of room for programs with deep nesting.
Many novice programmers indent improperly. They either don’t indent when they should indent, or they indent when they shouldn’t indent, or they use inconsistent widths for their indents. That leads to programs that are unprofessional looking and difficult to read. Some novice programmers postpone entering their in- dents until the end, after they’ve finished debugging. Big mistake! Use proper indentation as you enter your program. That should be pretty easy since there are really only two rules to remember:
1. Use braces to surround a block of code that is logically inside something else. 2. Indent the code that is inside the braces.