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