12.4 Implementation Attributes Not Defined in Java

< Day Day Up >

A number of implementation attributes have a generally accepted format in Java but are not enforced as part of the language or language definition. This section looks at some of them — specifically, naming conventions, indenting style, accessor methods, integrated development environments (IDEs), and source code management systems.

12.4.1 Naming Conventions

Naming conventions define standards for naming variables in a program. Naming conventions allow an identifier in a program to be easily associated with its type. In Java, it is generally accepted that classes start with an upper-case letter, and objects (variables that are instances of classes or primitives) start with a lower-case letter. This allows a programmer to quickly identify the Integer.parseInt method as being a static method in the class Integer and the myFrame.setSize method as being a method on the object myFrame. This is useful when trying to understand code fragments in a program. Exhibit 2 gives a list of the type of names used in Java, the rules for naming them, and an example of each type of name.

Exhibit 2: Naming Identifiers

Type of Identifier	How to Name
Primitive type	Use all lower-case letters (e.g., float, int).
Class or interface	Begin name with an upper-case letter, and begin each new word with an upper-case letter (e.g., TextArea).
Variable or method	Begin name with a lower-case letter, and begin each new word with an upper-case letter (e.g., myTextArea).
Constant	Use all upper-case letters and an underline (_) between each word (e.g., MAXIMUM_VALUE).
Package name	Use all lower-case letters (e.g., java.util); remember these names map to directory names, and so the package name must be able to be mapped to a directory name on the target system.

12.4.2 Indenting Style

Indenting style is the way that code appears between a start brace, "{", and an end brace, "}". The one correct style for indenting a program should be obvious to every programmer; unfortunately, programmers cannot agree on what that one correct style actually is. Indenting style is an issue of religion, where each person is absolutely convinced of the rightness of his cause. I will not try to put forth any one style as right or wrong, as it would add little to the debate, but I will offer the following council: Be consistent and be flexible. By being consistent I mean choose an indenting style and use it consistently. If you indent three spaces, always indent three spaces. If you put a start brace on a separate line, always put the start brace on a separate line. No matter what way you format an inner class or catch clauses, always format them that way. Nothing is more aggravating then reading a program with inconsistent indenting. It is extremely difficult to read and makes the programmer who wrote it look incompetent.

The second point is related to the first, be consistent and flexible. If you need to modify a program for which a programmer used the "wrong" indenting style, adopt that style for changes to the program. This will be extremely difficult for some readers to stomach, but all the other possible options are worse. As mentioned before, mixing indenting styles makes the program difficult to read, and, unless you have a very understanding boss, blowing a budget to rewrite what you consider invalid indenting could be detrimental to your career, especially if your boss uses the "wrong" indenting style and is equally religious about its use.

Finally, when indenting in an editor or IDE, you should consider using the option of saving tabs as blanks. The reason is simple in that most editors and IDEs handle tabs differently; when your source is moved to a new development environment, all your careful indenting will go for naught.

12.4.3 Accessor Methods

Accessor methods are used in Java to set and get properties (data values) in an object. They are also called setters and getters. In some languages, such as C#, these methods are formally defined and their use validated as part of the language definition. In Java, an informal definition for these methods can be enforced, especially when an object is used as a Java Bean. Accessor methods work on properties for an object — for example, the name variable for a Person class. This property is declared as a private identifier in the object. To access this variable, two methods are defined: one to set the property and one to get the property. These methods are named by adding the prefix "set" or "get" to the name of the property; for example, consider the name property in the Person class below:

   class Person {     private String name;     public void Person(String name) {       this.name = name;     }     public void setName(String name) {       this.name = name;     }     public String getName(String name) {       return name;     }   }

This is a standard way to handle properties in Java. One thing should be noted about this definition. In the setName method, the instance identifier "name" has been redefined by the local parameter identifier "name," requiring the use of the "this" qualifier to access the correct name. Many programmers react very badly to redefining an instance variable in a method and would force the parameter to use another name (for example, inputName); however, the redefinition of instance variable names is common in Java for constructors and accessor methods.

12.4.4 Interactive Development Environment (IDE)

An IDE is a program that includes an editor and specific functions for manipulating, compiling, and executing Java programs. Typical examples include Forte, Eclipse, Visual Café, or JBuilder. In Java, no one IDE is considered standard, as Java was written to work with any number of IDEs. This is not true of some languages, such as C#, which is designed to work with Visual Studio. The main thing to remember when using an IDE is that some IDEs provide nonstandard extensions to the language. These generally are not in the language definition, but in the implementation details. For example, an IDE might not use the standard Java compilation sequence and instead implement projects that behave differently than standard Java. Without a formal definition of what the IDE must do, a programmer must exercise care when using an IDE to ensure that the implementation attributes defined by working in that environment are actually what the programmer requires.

12.4.5 Source Code Control

No production project is complete until the issues involved in source code control are answered. How are changes to the system tracked? What backup/recovery mechanisms are in place? How are multiple accesses to source files controlled? What mechanisms are in place for distributing major and minor software releases? A number of tools are available to provide external system control over these source code issues, but many projects do not consider source code control problems until they have been adversely affected.

< Day Day Up >