1

CODING CONVENTIONS
INSTRUCTOR: PHAM HONG THANH
 2

NGUYEN PHAM THAI HOA

PRESENTERS
NGUYEN MINH THUAN
 3

1. File Name
2. File Organization
3. Identation
4. Comments
CONTENTS 5. Declarations
6. Statements
7. White Space
8. Naming Coventions
 4

What are the coding standards?

 5

What are the coding standards?

• Think of coding standards as a set of rules, techniques, and

best practices to create cleaner, more readable, more
efficient code with minimal errors.

• They offer a uniform format by which software engineers

can use to build sophisticated and highly functional code.
 6

Why have code convensions

 7

• 80% of the lifetime cost of a piece of software goes to maintenance.

• Hardly any software is maintained for its whole life by the original
author.
• Code conventions improve the readability of the software, allowing
engineers to understand new code more quickly and thoroughly.
• If you ship your source code as a product, you need to make sure it
is as well packaged and clean as any other product you create.
 8
Example: Your teammate asks you to
fix his code and he sends you code like
this.
9
 10

1.FILE NAME
 11

FILE SUFFIXES

COMMON FILE
NAMES
 12

2.FILE ORGANIZATION

Java source files have the following ordering:

• Header comments.
• Package and import statements.
• Class and interface declarations.
 13

2.1 HEADER
COMMENTS
 14

2.2 PACKAGE
AND IMPORT
STATEMENTS
 1. Class documentation comment. 15
2. Class declaration statement.
3. Class implementation comment.
4. Class implementation sections.

Should be presented in the following order: public,

protected, package-private (no modifier), private. Each class
implementation section should adhere to the following
2.3 CLASS structure (in order).
AND
1. Comment block.
INTERFACE 2. Constant declaration statements.
DECLARATION 3.
4.
Class variable declaration statements.
Instance variable declaration statements.
S 5. Constructors.
6. Methods.
7. If a main method exists it should be the last method in
the public implementation section.
8. Nested classes and interfaces.
 16

3.INDENTATION

3.1 Line Length

Avoid lines longer than 80 characters, since they're not
handled well by many terminals and tools.
 When an expression will not fit on a single line, break it 17
according to these general principles:

• Break after a comma.

• Break before an operator.
• Prefer higher-level breaks to lower-level breaks.
• Align the new line with the beginning of the expression at
the same level on the previous line.
3.1 Wrapping • If the above rules lead to confusing code or to code that's
Lines squished up against the right margin, just indent 8 spaces
instead.
Example:
• Break after a comma:
someMethod(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);

• Breaking an arithmetic expression:

longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6;
 18

4.COMMENTS

Java programs have two kinds of comments: implementaton

comments and documentation comments.
• Implementaton comments: block, single-line, trailing, and
end-of-line comment.
• Documentation comments describe Java classes,
interfaces, constructors, methods, and fields.
 Block comments are used to provide descriptions 19 of
files, methods, data structures, and algorithms. Block
comments may be used at the beginning of each file
and before each method.

The following is a simple example of a block

4.1.1 BLOCK comment.
COMMENTS /*
*Here is a block comment.
*/
 Short comments can appear on a single line. 20
A single-line comment should be preceded by a
blank line.

The following are a few examples of single-line

comments

4.1.2 SINGLE-
LINE COMMENTS
 Very short comments can appear on the same line21
as the code they describe but should be shifted far
enough to separate them from the statements.

The following are a few examples of trailing

comments.
....
4.1.3 TRAILING if (x == 2)
COMMENTS {
y = true; /* special case*/
}
else
{
z = isPrime(x); /* works only for odd*/
}
 The // comment delimiter begins a comment that 22
continues to the newline.

The following are examples of temporarily removing

code with comments.
....

4.1.4 END-OF-
LINE COMMENTS
 Each documentation comment is set inside the 23
comment delimiters /**...*/

The following is a simple example of a

documentation comment used for describing a class.

public class Student

4.2 {
DOCUMENTATION /**
COMMENTS * constructor documentation comment...
*/
public Student()
{
...
}

...
}
 24

5.DECLARATIONS
 5.1 NUMBER PER LINE 25

• Only one declaration per line

is allowed. Even though
Java permits multiple • The previous example uses a single space
declarations on a line, it between the type and the identifier. Another
makes initialization acceptable alternative is to use tabs.
impossible (see Section 6.2)
and leads to confusion when
scalars and arrays are
declared on the same line.
The standard Java
convention is to recommend
rather than require one
declaration per line.
 26
5.2 INITIALIZATION

• All variables (local and class) should be initialized where they are declared.
 5.3 PLACEMENT 27

• Put all local variable declarations at the beginning of method definitions

• The one exception to the placement rule is indexes of for loops which in Java can be
declared in the for statement.
• Avoid local declarations that hide declarations at higher levels. For example, do not
declare the same variable name in an inner block:
 28
5.4 Class and Interface
Declarations
• When coding Java classes and interfaces, the following formatting rules should be followed:

• No space between a method name and the parenthesis "(" starting its parameter list
• Open brace "{" appears at the end of the same line as the declaration statement
• Closing brace "}" starts a line by itself indented to match its corresponding opening
statement, except when it is a null statement the "}" should appear immediately after the "{"
• Methods are separated by a blank line
 29
6.Statements

Each line should contain at most one statement.

Example:

A return statement with a value should

not use parentheses unless they make
the return value more obvious in some
way. Example:
 30
6.Statements
• Format of the statement

• The if-else class of statements should have

the following form:

• A for statement should have the following

form

• A while statement should have the following

form

• A do-while statement should have the

following form

• A switch statement should have the following

form

• A try-catch statement should have the

following format
 31
7.White Space

• Regulations on the use of spaces (spaces), line headers, line breaks, blank lines:
to help the text content be organized in a systematic way for easy absorption by
readers.

• Blank Lines
• Blank lines improve readability by setting off sections of code that are logically
related.

• Blank Spaces
• A blank space should appear after commas in argument lists.
• All binary operators except . should be separated from their operands by
spaces.
 32
8.NAMING
CONVENTIONS
• Naming conventions make programs more understandable by making them easier
to read. They can also give information about the function of the identifier

• Packages Names
• The prefix unique package name is always written in all-lowercase ASCII
letters and sould be one of the top-level domain names, currently com, edu,
gov, mil, net, org, or one of the English two-letter codes identifying countries as
specified in ISO Standatd 3166,1981.
• Class and interface names
• Class and interface names should be noun
• Class and and interface names should be simple and descriptive.
• Class and interface should not contain prefixes to differntiate them from third-
party classes. Java's packaging mechanism is designed to obviate namespace
clashes.
 33
8.NAMING
CONVENTIONS
• Method names
• Method names should be verbs.
• Method names should be written in mixed case; the first word completely in
lowercase and the first letter of each subsequent word capitalized.
• For example:
 34
8.NAMING
• Variable names CONVENTIONS
• Variable names, in general, should be nouns.
• Variable names should be written in mixed case; the first word
completely in lowercase and the first letter of each subsequent word
capitalized.
• Variable names should be simple and descriptive.
• Variable names should not start with an underscore (_) or dollar sign ($)
character, even though both are allowed in Java.
• Single-character variable names should be avoided except for
temporary ``throwaway'' variables. Common names for temporary
variables are i, j, k, m, and n for integers; c, d, and e for characters.
 35
8.NAMING
• Constant names CONVENTIONS
• The names of variables declared class constants (static final) and of ANSI
constants should be all uppercase with words separated by underscores (_).
(ANSI constants should be avoided, for ease of debugging.)
 36

THANK
FOR
WATCHING