Java Coding Rules
Document number: UMT/OMC/APP/014701
Document issue: 01.01 / EN
Document status: Standard
Date: 08/Mar/2005
Confidential document - Not to be circulated outside Nortel
Copyright 2004 Nortel Networks, All Rights Reserved
Printed in France
NORTEL CONFIDENTIAL
The information contained in this document is the property of Nortel Networks. Except as specifically authorized in
writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential
and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for
evaluation, operation and maintenance purposes only.
The content of this document is provided for information purposes only and is subject to modification. It does not
constitute any representation or warranty from Nortel Networks as to the content or accuracy of the information
contained herein, including but not limited to the suitability and performances of the product or its intended
application.
This is the Way. This is Nortel, Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks. All
other trademarks are the property of their owners.
without notice. Nortel Networks assumes no responsibility for errors that might appear in t.All other brand and
Java Coding Rules
PUBLICATION HISTORY
8/Mar/2005
Issue 01.00 / EN, Draft
Creation
6/Apr/2005
Issue 01.01 / EN, Standard
Update after review
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 2/12
Java Coding Rules
CONTENTS
1. INTRODUCTION............................................................................................................................4
1.1. OBJECT ....................................................................................................................................4
1.2. SCOPE OF THIS DOCUMENT .......................................................................................................4
1.3. AUDIENCE FOR THIS DOCUMENT ................................................................................................4
2. RELATED DOCUMENTS ..............................................................................................................4
2.1. APPLICABLE DOCUMENTS ..........................................................................................................4
2.2. REFERENCE DOCUMENTS ..........................................................................................................4
3. SECURITY RULES ........................................................................................................................4
3.1. EXCEPTIONS ........................................................................................................................4
3.1.1 No empty catch ...............................................................................................................4
3.1.2 No redundant catch.........................................................................................................5
3.1.3 Avoid the NullPointerException.......................................................................................5
3.1.4 Never use the NullPointerException catch......................................................................6
3.1.5 Never use the ArrayIndexOutOfBoundsException catch................................................6
4. READABILITY ...............................................................................................................................6
4.1.1 Limit the class members visibility ....................................................................................6
4.1.2 Limit the nested if ............................................................................................................7
4.1.3 Limit the loops complexity ...............................................................................................8
4.1.4 Avoid the abusive string creation ....................................................................................9
4.1.5 No “implements” for constants use .................................................................................9
4.1.6 No “magic numbers”........................................................................................................9
4.1.7 Iterators ...........................................................................................................................9
4.1.8 Reduce variable scope....................................................................................................9
4.1.9 Short code lines ..............................................................................................................9
4.1.10 Do not use tab character...............................................................................................10
4.1.11 Naming conventions......................................................................................................10
4.1.12 Methods factorization ....................................................................................................10
4.1.13 Variable creation at use moment ..................................................................................10
4.1.14 Class methods order .....................................................................................................10
5. PERFORMANCE .........................................................................................................................11
5.1.1 Avoid appending to string within a loop ........................................................................11
5.1.2 Avoid multiple string concatenations.............................................................................11
6. ABBREVIATIONS AND DEFINITIONS.......................................................................................12
6.1. ABBREVIATIONS ......................................................................................................................12
6.2. DEFINITIONS ...........................................................................................................................12
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 3/12
Java Coding Rules
1. INTRODUCTION
1.1. OBJECT
This document defines the coding rules at the base off all access Java developments.
1.2. SCOPE OF THIS DOCUMENT
This document doesn’t represent an exhaustive description off all good base Java
practices (the knowledge and application is the responsibility of each designer) but is
a subset intended to ensure the code coherence, legibility and performance.
1.3. AUDIENCE FOR THIS DOCUMENT
This document is applicable to all OAM Java designers.
2. RELATED DOCUMENTS
2.1. APPLICABLE DOCUMENTS
2.2. REFERENCE DOCUMENTS
“Code Conventions for the Java Programming Language” by Sun
(http://java.sun.com/docs/codeconv/)
“Effective Java Programming Language Guide” by Joshua Bloch
3. SECURITY RULES
3.1. EXCEPTIONS
3.1.1 NO EMPTY CATCH
Don’t hide the issues!
By preference:
- fix the issue
- let the exception to go up
- trace the problem using the Trace API
- fill a comment in the catch and eventually print the stack trace
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 4/12
Java Coding Rules
If an API does not allow an exception to raise and if it is not clear what processing to
do, it is necessary to ask the API modification, otherwise redesign the code to avoid
the exception to rise)
Wrong
catch (Throwable e){
Right
catch (Throwable e){
// comment the time to fix the situation (redesign or API modification)
TraceAPI.trace(“An exception occurred”, e);
}
3.1.2 NO REDUNDANT CATCH
If the treatment is the same for all exceptions:
Wrong
catch (NumberFormatException e) {
return false;
catch (ModelException e) {
return false;
catch (Exception e) {
return false;
Right
catch (Exception e) {
return false
3.1.3 AVOID THE NULLPOINTEREXCEPTION
Such exception can rise only for methods called on a reference.
In all expressions like “myObj.doSomething()”, wonder if myObj can be null.
Tip: Use Null object pattern (object which do nothing but is not null)
Example: for a List getList() method, rather than returning a null list (in case of errors),
returns the Collections.EMPTY_LIST instance.
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 5/12
Java Coding Rules
3.1.4 NEVER USE THE NULLPOINTEREXCEPTION CATCH
Redesign the code to avoid catching the NullPointerException
Wrong
Lp_LogicalProcessor lp;
try {
lp = node.getLp(slot); //method which can rise a NullPointerException
}
catch (NullPointerException e) {
lp = node.createLp(slot);
}
Right
lp = node.findLp(slot) //method which return null
if(lp==null) lp = node.createLp(slot);
3.1.5 NEVER USE THE ARRAYINDEXOUTOFBOUNDSEXCEPTION
CATCH
Use the table field “length” in “for”.
Before to write myTab[n].xxx or myTab[n] = xxx, test systematically if n <
myTab.length.
4. READABILITY
4.1.1 LIMIT THE CLASS MEMBERS VISIBILITY
class MyOperation extends AbstractCustomOperation {
public static final String PARAM = “toto”;
private Map myMap = new HashMap();
public boolean isEnabled(MO mo) {
...
doSomething(mo);
...
}
private void doSomething(MO mo) {
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 6/12
Java Coding Rules
…
}
In this code:
PARAM is public because is a constant used somewhere else (in tests for example)
MyMap is private because is a class member data and the others class must not have
access.
doSomething is private because it is an implementation function which must not be
used somewhere else.
By default, all declarations must be made private and changed to protected and after
to public only if good reason is identified.
Basically member class variables are made private and modifications are done via
accessors.
4.1.2 LIMIT THE NESTED IF
Use the “fail fast” technique, opposed to “one return by method” current philosophy:
Wrong
public void foo(MyObject a) {
if (a != null) {
MyObject b = a.computeB();
if (b != null) {
b.doSomething();
MyObject c = b.findC();
if (c != null) {
// ...
}
}
}
Right
public void foo(MyObject a) {
if (a == null) {
return;
}
MyObject b = a.computeB();
if (b == null) {
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 7/12
Java Coding Rules
return;
}
b.doSomething();
MyObject c = b.findC();
if (c == null) {
return;
}
// ...
Tip: use “invert if condition” under IntelliJ.
4.1.3 LIMIT THE LOOPS COMPLEXITY
Use return/break/continue rather the stop Booleans.
Wrong
boolean found = false;
Iterator nodeBs = rncTarget.
getChildrenOfType(NodeBConstants.TYPE_ID);
while (!found && nodeBs.hasNext()) {
ManagedObject nodeB = ((ManagedObject)nodeBs.next());
Iterator fddCells = nodeB.
getChildrenOfType(FDDCellConstants.TYPE_ID);
while (!found && fddCells.hasNext()) {
target = (ManagedObject)fddCells.next();
found = target.getKeyValue().toString().
equals(fddCellIdTarget);
}
return target;
Right
for (Iterator nodeBs = rncTarget.
getChildrenOfType(NodeBConstants.TYPE_ID);
nodeBs.hasNext();) {
ManagedObject nodeB = ((ManagedObject)nodeBs.next());
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 8/12
Java Coding Rules
for (Iterator fddCells =
nodeB.getChildrenOfType(FDDCellConstants.TYPE_ID);
fddCells.hasNext();) {
ManagedObject target = (ManagedObject)fddCells.next();
if (target.getKeyValue().toString().
equals(fddCellIdTarget)) {
return target;
}
}
return null;
4.1.4 AVOID THE ABUSIVE STRING CREATION
For foo(nb + "") wonder if is not better to write foo(int)
4.1.5 NO “IMPLEMENTS” FOR CONSTANTS USE
4.1.6 NO “MAGIC NUMBERS”
No literal value in the code – use systematically class defined constants
int[] slots = new int[16] : use the constant PpDefs.NB_SLOTS. (“Once and
Only Once”
4.1.7 ITERATORS
Iterations must be implemented using for:
for (Iterator iterator = collection.iterator();
iterator.hasNext();) {
MyObj o = (MyObj) iterator.next();
// ...
4.1.8 REDUCE VARIABLE SCOPE
Variables must be defined where need them and not at the method beginning (C
practice not good for the legibility)
4.1.9 SHORT CODE LINES
Limit the lines codes to 120 character facilitate the code reviews by avoiding the
horizontal scroll bars use
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 9/12
Java Coding Rules
4.1.10 DO NOT USE TAB CHARACTER
Editors must be set to automatically replace tab character by space characters.
4.1.11 NAMING CONVENTIONS
thepackagenamesarelowercaseandareshorts
TheClassNamesAreCapitalizedAndBeginsWithACapital
theMethodNamesAndVariablesAreCapitalizedAndBeginsWithALowerCase
Use the JavaBeans conventions for the accessors: toto.getThings() rather than
toto.things().
For method names, use the imperative form: “processSomething” rather than
“something“.
Avoid the comic names as “runAutoFix4Conan” or “nodes2Delete”. Use rather
“runAutoFixForConan” and “nodesToDelete”
4.1.12 METHODS FACTORIZATION
Don’t create an abstract class if no common state. Rather define static method in an
external tool class. ENSURE that such static method do not received a huge number
of arguments (among which some kind of state can be passed).
4.1.13 VARIABLE CREATION AT USE MOMENT
Wrong
int atmifCAMaxVccsValue = 0;
…
atmifCAMaxVccsValue = xxx;
Right
int atmifCAMaxVccsValue = xxx;
4.1.14 CLASS METHODS ORDER
While implementing an interface follow the methods order in the interface. This helps
the reviewer to understand the code
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 10/12
Java Coding Rules
5. PERFORMANCE
5.1.1 AVOID APPENDING TO STRING WITHIN A LOOP
Performance enhancements can be obtained by replacing String operations with
StringBuffer operations if a String object is appended to within a loop.
Wrong
public class ATSWL {
public String func () {
String var = "var";
for (int i = 0; i < 10; i++) {
var += (" " + i);
}
return var;
}
Tip: Use StringBuffer class instead of String
Right
public class ATSWL {
public String func () {
StringBuffer var = new StringBuffer("var");
for (int i = 0; i < 10; i++) {
var.append(" " + i);
return var.toString();
}
5.1.2 AVOID MULTIPLE STRING CONCATENATIONS
String classes are designed to be immutable, and every method in the class that
appears to modify a String actually creates and returns a brand new String object
containing the modification. The original String is left untouched, but the compiler can
optimize your code.
Using StringBuffer instead of String for multiple mutable operations is better for
performance.
Wrong
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 11/12
Java Coding Rules
private String getHtmlOut() {
String htmlOut;
htmlOut = "<html>";
...
htmlOut += "<body>";
...
htmlOut += "The record not found";
...
htmlOut += "</body></html>";
return htmlOut;
}
Right
private String getHtmlOut() {
StringBuffer htmlOut=new StringBuffer(100);
htmlOut.append("<html>");
...
htmlOut.append("<body>");
...
htmlOut.append("The record not found");
...
htmlOut.append("</body></html>");
return htmlOut.toString();
}
6. ABBREVIATIONS AND DEFINITIONS
6.1. ABBREVIATIONS
6.2. DEFINITIONS
END OF DOCUMENT
Nortel confidential
UMT/OMC/APP/014701 01.01 / EN Standard 08/Mar/2005 Page 12/12
