You are on page 1of 41

Java Code Conventions Quick Reference http://java.sun.

com/docs/codeconv/

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
Return statements while statements switch statements

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
1. Do not enclose the return value in parentheses Use the following format: Use the following format:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
unless they make the return value more while (condition) { switch (condition) {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
obvious in some way. statements; case ABC:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
2. Make the structure of your code match its } statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
intent: /* falls through */

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
Replace this if-else statement: for statements

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
if (booleanExpression) { Use the following format: case DEF:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return true; for (initialization; condition; update) { statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
} else { statements; break;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return false; }

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
} Declare the loop control variable inside for-loop: default:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
with a return statement: for (int i = 0; i < size; ++i) { statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return booleanExpression; statements; break;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
Replace this code fragment: } }

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
if (condition) { 1. Always include default case.

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return x; do-while statements 2.Use the comment line /* falls through

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
} Use the following format: */ when the case label does not have

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return y; do { a break statement.

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
with a return statement: statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
return (condition ? x : y); } while (condition); try-catch blocks

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
Use the following format:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
Ternary statements if-else statements try {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
The following formats are acceptable: Use the following formats: statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
a = condition ? b : c; if (condition) { } catch (ExceptionClass e) {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
a = condition ? b statements; statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
: c; } }

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
a = condition if (condition) {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
? b statements; Line wrapping for if-statements

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
: c; } else { Use 8 space rule (2 tabs) when wrapping

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
1. Parentheses around condition are optional. statements; an if-statement so body is easier to see:

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
2. Use parentheses when the condition is a binary } if ((a && b)

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
expression: if (condition) { || (c && d)

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
absoluteValue = (x >= 0) ? x : -x; statements; || (e && f)) {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
3. Avoid nested ternary statements. } else if (condition) { statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
4. Use conditional operator, not if-else statement, statements; }

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
when assigning a value to a variable: } else {

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
a = condition ? b : c; statements;

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


Indentation Implementation comments Naming conventions
1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep
2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations.
the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed
when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized.
3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener
4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first
classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal
5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground
overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first
Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal
1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize
2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated
the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE
class Example { */
statement; // trailing comment Blank lines
private void doTask() { Use one blank line:
Javadoc comments: 1. Before a comment
statements; 1. Use to document classes, interfaces, 2. Between methods
} methods, and variables (with class-scope). 3. After a method header
}
2.Should describe the entity being documented 4. After a block of local variable declarations
from an implementation-free perspective. 5. Between logical sections of code so that logically-
Miscellaneous /** related statements are grouped
1. Avoid lines longer than 80 characters. * Javadoc comment
2. One statement per line. */ Spaces
3. One declaration per line. /** Javadoc comment */ Use a space:
4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis
except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists
5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands
for-loop—contains a single statement, the 1. Break after a comma (see exception below)
single statement should be enclosed in braces. 4. To separate a ternary operator from its operands.
6. Use the class name, not a reference, to access
2.Break before a binary operator
5. Between initialization, expression, and update
static methods and variables. 3. Prefer high-level breaks to low-level breaks
parts of a for-loop
7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression
6. After a cast
evaluation in complex expressions. (or argument list) on previous line:
a = b * (c + d – e) Do not use a space:
8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands
+ (f / g);
well-named symbolic constant instead. 2. Between a unary operator and its operand
x = getValue(a + b + c,
(Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis
d + e + f);
5. If these rules lead to confusing code or code
that’s jammed up against the right margin,
indent 8 spaces (2 tabs) instead.
}

© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.


© Copyright 1999-2004, iCarnegie, Inc. All rights reserved.