Some Coding Guidelines

www.cs.uoi.gr/~zarras/http://www.cs.uoi.gr/~zarras/se.htm
Don'ts & Do’s

 Don’t mix the data model and the logic of the

application with the GUI classes of the application.
 Classes
 Make classes small and cohesive - A single well defined
responsibility for a class
 Don’t break encapsulation by making the data representation
public
 Class names are important – use descriptive names for the
concepts represented by the classes
 Use Noun & Noun phrases for class names
 See here for more - http://www.cs.uoi.gr/~zarras/soft-
devII.htm
Don'ts & Do’s
 Methods
 Make methods small – A method must do one thing
 Method names are important – use descriptive names for the
concepts represented by the methods
 Use Verb & Verb phrases for method names
 See here for more - http://www.cs.uoi.gr/~zarras/soft-
devII.htm
 Fields
 Make fields private – A method must do one thing
 Field names are important – use descriptive names for the
concepts represented by the fields
 Use Noun & Noun phrases for field names
Conventions
 Source file organization
 A Java source file should contain the following
elements, in the following order:
 Copyright/ID block comment
 package declaration
 import declarations
 one or more class/interface declarations
 At least one blank line should separate all of these
elements.
Conventions
 Package naming
 Generally, package names should use only lower-
case letters and digits, and no underscore.
Examples:
 java.lang
 java.awt.image
 dinosaur.theropod.velociraptor
Conventions
 Class/Interface naming
 All type names (classes and interfaces) should use the
InfixCaps style.
 Start with an upper-case letter, and capitalize the first
letter of any subsequent word in the name, as well as
any letters that are part of an acronym. All other
characters in the name are lower-case.
 Do not use underscores to separate words.
 Class names should be nouns or noun phrases.
 Examples:
 // GOOD type names:
 LayoutManager, AWTException, ArrayIndexOutOfBoundsException
 // BAD type names:
 ManageLayout // verb phrase
 awtException // first letter lower-case
 array_index_out_of_bounds_exception // underscores
Conventions
 Field naming
 Names of non-constant fields (reference types, or non-
final primitive types) should use the infixCaps style.
 Start with a lower-case letter, and capitalize the first
letter of any subsequent word in the name, as well as
any letters that are part of an acronym. All other
characters in the name are lower-case.
 Do not use underscores to separate words.
 The names should be nouns or noun phrases.
 Examples:
 int index;
 String color;
 Names of fields being used as constants should be all
upper-case, with underscores separating words.
 Examples:
 MIN_VALUE, MAX_BUFFER_SIZE, OPTIONS_FILE_NAME
Conventions
 Method naming
 Method names should use the infixCaps style.
 Start with a lower-case letter, and capitalize the first
letter of any subsequent word in the name, as well as any
letters that are part of an acronym. All other characters in
the name are lower-case.
 Do not use underscores to separate words.
 Method names should be imperative verbs or verb
phrases. Examples:
 // GOOD method names:
 showStatus(), drawCircle(), addLayoutComponent()
 // BAD method names:
 mouseButton() // noun phrase; doesn’t describe function
 DrawCircle() // starts with upper-case letter
 add_layout_component() // underscores
Conventions
 Blank lines
 A blank line should also be used in the following
places:
 After the copyright block comment, package
declaration, and import section.
 Between class declarations.
 Between method declarations.
 Between the last field declaration and the first method
declaration in a class.
Conventions
 Blank spaces
 A single blank space (not tab) should be used:
 Between a keyword and its opening parenthesis. This applies to
the following keywords: catch, for, if, switch, while.
 After any keyword that takes an argument.
 Example: return true;
 Between two adjacent keywords.
 Before and after binary operators except .(dot).
 After a comma in a list.
 After the semi-colons in a for statement, e.g.:
 for (expr1; expr2; expr3) {
Conventions
 Continuation lines
 Lines should be limited to 80 columns.
 Lines longer than 80 columns should be broken into one or
more continuation lines, as needed.
 All the continuation lines should be aligned
 // RIGHT
 foo(long_expression1, long_expression2, long_expression3,
long_expression4);
 // RIGHT
 foo(long_expression1,
long_expression2,
long_expression3,
long_expression4);
Conventions
 Classes
 A class declaration looks like the following.
Elements in square brackets [] are optional.

[ClassModifiers] class ClassName [Inheritances] {

1. Static variable field declarations
2. Instance variable field declarations
3. Static method declarations
4. Constructor declarations
5. Instance method declarations
}
Conventions
 Method declarations
 All of the elements of a method declaration up to and
including the opening brace “{” should appear on a single line
 (unless it is necessary to break it up into continuation lines if it
exceeds the allowable line length).
 A method declaration looks like the following. Elements in
square brackets “[” are optional.
[MethodModifiers] Type MethodName(Parameters) [throws Exceptions] {
Method Body
}
Conventions
 Simple statements
 Assignment and expression statements
 Each line should contain at most one statement. For example,
 a = b + c; count++; // WRONG
 a = b + c; // RIGHT
 count++; // RIGHT
Conventions
 Simple statements
 Local variable declarations
 Generally local variable declarations should be on separate
lines;
 however, an exception is allowable for temporary variables that do
not require initializers. For example,
 int i, j = 4, k; // WRONG
 int i, k; // acceptable
 int j = 4; // RIGHT
Conventions
 Simple statements
 Array declarations
 The brackets “[]” in array declarations should immediately
follow the array name, not the type.
 The exception is for method return values, where there is no
separate name; in this case the brackets immediately follow the type:
 char[] buf; // WRONG
 char buf[]; // RIGHT
 String[] getNames() { // RIGHT, method return value
Conventions
 if statement
if (condition) {
statements;
}

if (condition) {
statements;
} else {
statements;
}

if (condition) {
statements;
} else if (condition) {
statements;
} else {
statements;
}
Conventions
 for statement
for (initialization; condition; update) {
statements;
}
 while statement
while (condition) {
statements;
}
Conventions
 switch statement
switch (condition) {
case 1:
case 2:
statements;
break;
case 3:
statements;
break;
default:
statements;
break;
}