Coding Standards.
■ Classes and interfaces The first letter should be capitalized, and if several words are linked together to form the name, the first letter of the inner words should be uppercase (a format that's sometimes called "camelCase"). For classes, the names should typically be nouns.
For example:
Dog
Account
PrintWriter
For interfaces, the names should typically be adjectives like
Runnable
Serializable
■ Methods The first letter should be lowercase, and then normal camelCase rules should be used. In addition, the names should typically be verb-noun pairs.
For example:
getBalance
doCalculation
setCustomerName
■ Variables Like methods, the camelCase format should be used, starting with a lowercase letter. Sun recommends short, meaningful names, which sounds good to us.
Some examples:
buttonWidth
accountBalance
myString
■ Constants Java constants are created by marking variables static and final. They should be named using uppercase letters with underscore characters as separators: MIN_HEIGHT
- Use access modifier with proper requirement.
- For constant declaration use Enum with example
- prefix use based on class name
- layout name give based on meaning and use.
- use inheritance and polymorphism
- Use JavaDoc for every Class,Method,Object etc... description
JavaBeans Standards
First, JavaBeans are Java classes that have properties. For our purposes, think of properties as private instance variables. Since they're private, the only way they can be accessed from outside of their class is through methods in the class. The methods that change a property's value are called setter methods, and the methods that retrieve a property's value are called getter methods. The JavaBean naming rules that you'll need to know for the exam are the following:
JavaBean Property Naming Rules
■ If the property is not a boolean, the getter method's prefix must be get. For example, getSize()is a valid JavaBeans getter name for a property named "size." Keep in mind that you do not need to have a variable named size (although some IDEs expect it). The name of the property is inferred from the getters and setters, not through any variables in your class. What you return from getSize() is up to you.
■ If the property is a boolean, the getter method's prefix is either get or is. For example, getStopped() or isStopped() are both valid JavaBeans names for a boolean property.
■ The setter method's prefix must be set. For example, setSize() is the valid JavaBean name for a property named size.
■ To complete the name of a getter or setter method, change the first letter of the property name to uppercase, and then append it to the appropriate prefix (get, is, or set).
■ Setter method signatures must be marked public, with a void return type and an argument that represents the property type.
■ Getter method signatures must be marked public, take no arguments, and have a return type that matches the argument type of the setter method for that property.
Second, the JavaBean spec supports events, which allow components to notify each other when something happens. The event model is often used in GUI applications when an event like a Button click is multicast to many other objects that may have things to do when the mouse click occurs. The objects that receive the information that an event occurred are called listeners. For the exam, you need to know that the methods that are used to add or remove listeners from an event must also follow JavaBean naming standards:
JavaBean Listener Naming Rules
■ Listener method names used to "register" a listener with an event source must use the prefix add, followed by the listener type. For example, addActionListener() is a valid name for a method that an event source will have to allow others to register for Action events.
■ Listener method names used to remove ("unregister") a listener must use the prefix remove, followed by the listener type (using the same rules as the registration add method).
■ The type of listener to be added or removed must be passed as the argument to the method.
■ Listener method names must end with the word "Listener".
Examples of valid JavaBean method signatures are
public void setMyValue(int v)
public int getMyValue()
public boolean isMyStatus()
public void addMyListener(MyListener m)
public void removeMyListener(MyListener m)
Examples of invalid JavaBean method signatures are
void setCustomerName(String s) // must be public
public void modifyMyValue(int v) // can't use 'modify'
public void addXListener(MyListener m) // listener type mismatch
Source File Declaration Rules
Before we dig into class declarations, let's do a quick review of the rules associated
with declaring classes, import statements, and package statements in a source file:
■ There can be only one public class per source code file.
■ Comments can appear at the beginning or end of any line in the source code file; they are independent of any of the positioning rules discussed here.
■ If there is a public class in a file, the name of the file must match the name of the public class. For example, a class declared as public class Dog { } must be in a source code file named Dog.java.
■ If the class is part of a package, the package statement must be the first line in the source code file, before any import statements that may be present.
■ If there are import statements, they must go between the package statement (if there is one) and the class declaration. If there isn't a package statement, then the import statement(s) must be the first line(s) in the source code file. If there are no package or import statements, the class declaration must be the first line in the source code file.
■ import and package statements apply to all classes within a source code file. In other words, there's no way to declare multiple classes in a file and have them in different packages, or use different imports.
■ A file can have more than one nonpublic class.
Reference from SCJP book
