Code Review Check List and Best Practices

7/27/2019 Code Review Check List and Best Practices

1/13

Check List

Page 1


2/13

Check List

Page 2


3/13

Check List

Page 3


4/13

Check List

Page 4

Java Source Code Standards Check List

Item

File Headers

Does each file have the correct header?

Naming Conventions

Do all packages start with "com.your.domain.name"?

Are package names single lowercase words with no spaces, dashes or special characters (com.domain.acka

Do class names start with a capital letter followed by mixed case (FooBarReader)?

Do member functions, variables, and parameters start with a lowercase letter followed by mixed case witho

Do debug-only classes and methods start or end with debug?

Are factory classes named xxxFactory with MakeXxx functions?

Are getters and setters named getXxx and setXxx and appropriately consistent with the Java Bean spec

Are Boolean getters named isXxx, canXxx, hasXxx, or willXxx?Do methods which return several items of information end in List (getFooList)?

Do initialization methods named init()?

Are all class variables appropriately prepended with their scope?

Are constants all uppercase with underscores separating words? (THIS_IS_A_CONSTANT)

Are variable names clear (more than characters except for short loops and immediate usage)?

Do variable names use contractions which are obvious?

Do variable names match obvious sources (for example, SQL column names)?

Code Indentation

Do braces line up vertically with the code indented from the braces?

Commenting Code

Does the package have a packagehtml file describing the basic purpose of the package and how to use its cl

Does every public class, method and variable have a JavaDoc comment which adequately explains how to u

method or variable?

Do implementations of interfaces or super-class functions rely on the interface/super-class JavaDoc comme

Does the code together with its comments adequately explain how the code operates?

Are the following grouped separately with commented markers: constructors, public functions, other functi

object functions [toString(), equals()], test harness [main()]?

For libraries: Does each public class have a javadoc comment including information on:Typical Usage (designed to be used as is or extended with sub-class)

Life Cycle (how class is expected to be used in the program)

Synchronization (whether thread safe; if thread safe, how?)

ROBUSTNESS

Synchronization


5/13

Check List

Page 5

Is access to non-final static variables (glb or cls) synchronized?

If the class is designed to be used in an EJB, does it avoid non-final static variables entirely?

Parameters, Variables, Constants

Are the correct parameters passed? That is, do the calling and called parameters match?

Have magic numbers been replaced by constants?Are all object references checked for null before usage?

Are class casts made safely (usually by checking with an instanceof)?

Are object variables which do not immediately fall out of scope set to null when no longer needed?

Are numeric parameters checked for correct range before usage?

Computation

Are parenthesis used instead of depending on operator precedence and used correctly?

Are intermediate results stored instead of recomputed?

Is conversion between integers and floats appropriately handled?

Exit Points

Are all intermediate exit points necessary, appropriate, and obvious?Is all necessary cleanup done before exiting (especially when exiting from try/catch blocks)?

Does method only exit through normal means (eg does not call Systemexit())?

Looping

If looping over an indexed variable, is the index counter correctly set to the size of the indexed variable?

Is the loop guaranteed to terminate?

Branching/Switching

Does each case which has code end in either a break or a comment that it deliberately intends to fall throug

Is there a default case to handle unexpected input?

Miscellaneous

Divided by zero handled?

MAINTAINABILITY

Coupling

No public variables without strong justification in comments

Do the classes avoid using protected and package/friendly variables of other classes in the same package?

Program Messages/Log Entries

Are messages understandable?

Does the message adequately describe the source of the problem so a programmer can find the problem (cla

Does the message adequately tell the user what the user can do (keep working, kill program, etc)?Does the message read like a human talking (and not like a robot)?

Does the message use correct grammar?

Does the message keep the user free from any blame or fear (eg does not say "You moron! You pressed the

Miscellaneous

Is each class, method, and variable used and used only for a single purpose?


6/13

Check List

Page 6

Does the class make use of available class libraries?

FUNCTIONALITY

Does package meet design requirements?

Does the code match the design specification?Does the code create any performance bottlenecks or problems?


7/13

Check List

Page 7

Yes/No


8/13

Check List

Page 8


9/13

Check List

Page 9


10/13

Best Practices

Page 10

Best practices in Java Coding

S.No Topic Description1 Common Practices

Avoid basic style errors

Avoid raw types

Beware of instanceof operator

Class for constants

Construct classes from the outside in

Do not break portability

Don't declare local variables before use

Fields should usually be private

Interface for constants

Know the core libraries

Minimize ripple effects

Naming conventions

Output parameters

Separate public and private membersString concatenation does not scale

Tag or marker interfaces

Uncommon classes need explicit imports

Use @Override liberally

Use final liberally

Use javadoc liberally

Use static imports rarely

Use System.exit with care

Use Version Control tools

Validate method arguments

Wisdom, not rules

2 Inheritance

Consider composition instead of subclassing Designing for subclassing

Overridable methods need special care

Remember styles of inheritance

3 Constructors

Avoid JavaBeans style of construction

Beware of mistaken field redeclares

Construct Object using class name Constructors in general

Constructors shouldn't call overridables Constructors shouldn't start threads

Copy constructors Don't let this reference escape

Initializing fields to 0-false-null is redundant

4 Exceptions

Avoid @throws in javadoc

Avoid empty catch blocks

Be specific in throws clause

Beware of unknown root causes

Checked versus unchecked exceptions


11/13

Best Practices

Page 11

Exception translation

Exceptions and control flow

Finally and catch

Javadoc all exceptions

Pass all pertinent data to exceptions

Convert Stack trace into StringUse template for repeated try-catch

5 Collections

Choosing the right Collection

Encapsulate collections

Iterate without an index

Prefer Collections over older classes

Two ways of using Iterator (for and while)

Use for-each liberally

Use interface references to Collections

Use standard Collections

6 Serialization

Implementing Serializable

Serialization and subclassing

Some classes need readResolve

7 Threads

Always shut down an ExecutorService

Avoid ThreadGroup

Data integrity first

Document thread safety

Dump thread information

Handle InterruptedExceptionLaunch thread is just another user thread

Objects communicating across threads

Perform N tasks in parallel

Prefer modern libraries for concurrency

Query host for the number of processors

Read-write locks

Remember the types of intrinsic lock

Schedule periodic tasks

Stop threads through cooperation

Synchronize access to mutable fields

Synchronized is implementation detail

Thread priorities are not portableUse finally to unlock

8 More Common Practices

Avoid null if possible

Beware of Byte Order Marks

Beware of DecimalFormat

Beware of floating point numbers


12/13

Best Practices

Page 12

Clarifying method

Coding conventions

Compile regular expressions once

Conditional compile

Consider code generators

Consider immutable forms for datesConventional name for return value

Defensive copying

Design by Contract

Generating unique IDs

Include 'from', exclude 'to'

Multiple return statements

Overloading can be tricky

Package by feature, not layer

Passwords never in clear text

Prefer empty items to null ones

Quote dynamic text when logging

Self-encapsulate fieldsStructs are occasionally useful

Avoid Test using main method

Try alternatives to ResourceBundle

Use a fake system clock

Use a testing framework (JUnit)

Use Ant for build scripts

Use boxing with care

Use enums to restrict arguments

Validate state with class invariants

Validation belongs in a Model Object

9 Overriding Object MethodsAvoid clone

Implementing compareTo

Implementing equals

Implementing hashCode

Implementing toString

Never rely on finalize

10 Database Interaction

Business identifiers as String

Connection pools

Consider data layer tools

Consider using standard SQLConsider wrapper classes for optional data

Data access objects

Data exception wrapping

Data is king

Don't perform basic SQL tasks in code

Encapsulate connections

Keep SQL out of code


13/13

Best Practices

Page 13

Prefer PreparedStatement

Reduce database code duplication

Remember the basics of database design

Simplify database operations

Try pseudo-persistence for mock ups

Use template for transactions

11 Input-Output

Always close streams Buffering usually appropriate

Use Console input

Copy a file (use File.copy())

Reading and writing binary files

Reading and writing Serializable objects

Reading and writing text files

12 Common Design Patterns

Abstract Factory

Command objectsFactory methods

Immutable objects

Lazy initialization

Model Objects

Plugin Factory

Private constructor

Singleton

Template method

Type-Safe Enumerations

Wrapper (Decorator)

13 Memory Management

1. Memory Leaks

a. Avoid Mutable Static Fields and Collections

b. Thread-Local Variables should be defined as necessarily

2. Excessive Memory Use

Incorrect Cache Usage

Session Caching

3. Classloader-Related Memory Issues

Large Classes

4. Out-Of-Memory Errors

c. Avoid Circular and Complex Bi-Directional References

Documents

Code Review Check List and Best Practices