|
||||||||||||||
|
||||||||||||||
|
|
|
|||||||||||||||||||||||||
Package names should all be in lower case:
mypackage, java.beans, java.beans.beancontext
Package naming convention used by Sun for the Java core packages. The initial package name representing the domain name must be in lower case.
Class or type names hould be nouns and written in mixed case starting with upper case:
MyClass, Object, ArrayList
Naming convention used by Sun in the Java core packages
Variable names should be in mixed case, beginning with lower case:
myVariable, newName, nextItem
Naming convention for variables used by Sun in the Java core packages. Makes variables easy to distinguish from classes, and easily allows a variable to be given the same name as its type if appropriate: ArrayList arrayList.
Names for constants (any variable declared as final) must be all uppercase using underscore to separate words.
MAX_HEIGHT, EXIT_ON_CLOSE, TOP_ALIGNMENT
Naming convention used by Sun for the Java core packages. Alternative: in many cases implementing the value as a method is a better choice:
int getMaxIterations() // NOT: MAX_ITERATIONS = 25
{
return 25;
}
This form is easier to read, and ensures a uniform interface towards class values.
Method names should be verbs and written in mixed case starting with lower case.
myMethod, getWidth, setName, start
Naming convention used by Sun for the Java core packages.
Abbreviations and acronyms should not be uppercase when used as name.
openHtmlPage(); // NOT openHTMLPage exportUmlToDisk(); // NOT exportUMLToDisk
Having an acronym all in uppercase does not make the acronym stand out in a name and reduces readability.
Generic variable names should have the same name as their type.
void setDimension (Dimension dimension) // NOT: void setDimension (Dimension value) // NOT: void setDimension (Dimension aDimension) // NOT: void setDimension (Dimension x)
void connect (Database database) // NOT: void connect (Database db) // NOT: void connect (Database oracleDB)
This reduces the complexity of your code and makes it easy to deduce the type of a variable from its name. If for some reason this convention doesn't seem to fit it is a strong indication that the type name is badly chosen.
Generic or non-generic? Non-generic variables have a role to perform in your code. These variables can often be named by combining role and type:
Point startingPoint, centerPoint; Name loginName;
Keep your lines to 80 columns maximum. 80 columns is the common dimension for editors, terminal emulators, printers and debuggers, and files that are shared between several developers should keep within these constraints. It improves readability when unintentional line breaks are avoided when passing a file between programmers.
NEVER use tabs or page breaks in your code. These characters are interpreted differently by different programs in different environments and will cause your code to look differently when other programmers view it (i.e. your marker!).
Always make sure your editor (Bluej included) is using tabs only - and not spaces.
Split lines
newTotal = a + b + c +
d + e);
myMethod (int firstNumber, int secondParam,
int thirdParam);
setText ("Long line split"
"into two parts.");
for (index = 0; index < maxValue;
index += indexStep)
Split lines occurs when a statement exceed the 80 column limit given above. It is difficult to give rigid rules for how lines should be split, but the examples above should give a general hint.
In general:
Break after a comma.
Break after an operator.
Align the new line with the beginning of the expression on the previous line.
Indentation standard is three spaces. Make sure your indentation is kept regular throughout your code - each new block should have another level of indentation.
Warning: if you have more than three levels of indentation inside a method, consider making a new method out of that code.
Use one of the first two; never use the third:
// OK to use for (int index = 0; index < maxValue; index ++) { doSomethingInteresting (); someValue = someThingElseInteresting (); } // OK to use for (int index = 0; index < maxValue; index ++) { doSomethingInteresting (); someValue = someThingElseInteresting (); } // NEVER use! for (int index = 0; index < maxValue; index ++) { doSomethingInteresting (); someValue = someThingElseInteresting (); }
Use the same rules for try-catch-finally, if, if-else, while, do, for, case, synchronized, method and class blocks.
Use the following rules for putting space in your code lines.
Conventional operators should be surrounded by a space character.
Java reserved words should be followed by a white space.
Commas should be followed by a white space.
Colons should be surrounded by white space.
Semicolons in for statements should be followed by a space character.
Examples:
a = (b + c) * d; // NOT: a=(b+c)*d
while (true) { // NOT: while(true) ...
doSomething (a, b, c, d); // NOT: doSomething (a,b,c,d);
case 100 : // NOT: case 100:
for (i = 0; i < 10; i++) { // NOT: for (i=0;i<10;i++){
This helps to make parts of your code stand out from each other, improving the readability of your code.
Method names should be followed by a space when there paramaters.
doSomething (paramaterValue); // NOT: doSomething(paramaterValue); doSomethingElse(); // NOT: doSomethingElse ();
This helps to make the method name stand out from the paramater names. When there are no paramaters, leave out the space because there can be no doubt about the name of the method.
Always use three to five blank lines between methods - but decide on the number and keep it consistent!
Only declare one variable per line.
int one, two, three; // NO: not very readable int one; // YES: much clearer int two; int three;
Comment like your life depends on it!
Single or double line comments, use the following form:
// This type of comment can be one // or maybe two lines
Non javadoc comments that take up more than two lines should be in a multi-line comment box. Note the indentation used!
/*
This is a more substantial comment
that the author feels important enough
to put here over several lines
*/
javadoc faq section
[1] Java Programming Style Guidelines, Version 3.0, January 2002 for Geotechnical Software Services
http://geosoft.no/javastyle.html
These pages were created by Robert Mark Bram using Macromedia DreamWeaver UltraDev 4.0.
Have something to ad? Comments or corrections? Tell me about it now!
