Check List

Page 1

Check List

Page 2

Check List

Page 3

Check List

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.ackage)? 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 without under 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 specification 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 classes? Does every public class, method and variable have a JavaDoc comment which adequately explains how to use the c method or variable? Do implementations of interfaces or super-class functions rely on the interface/super-class JavaDoc comment? 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 functions, inn 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
Page 4

Check List

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 through to the 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 (classmetho 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 wrong Miscellaneous Is each class, method, and variable used and used only for a single purpose?
Page 5

Check List

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?

Page 6

Check List

Yes/No

Page 7

Check List

Page 8

Check List

Page 9

Best Practices

Best practices in Java Coding

S.No Topic
1 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 members String 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 Page 10

Description

Best Practices Exception translation Exceptions and control flow Finally and catch Javadoc all exceptions Pass all pertinent data to exceptions Convert Stack trace into String Use 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 InterruptedException Launch 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 portable Use finally to unlock 8 More Common Practices Avoid null if possible Beware of Byte Order Marks Beware of DecimalFormat Beware of floating point numbers Page 11

Best Practices Clarifying method Coding conventions Compile regular expressions once Conditional compile Consider code generators Consider immutable forms for dates Conventional 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 fields Structs 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 Methods Avoid 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 SQL Consider 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 Page 12

Best Practices 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 objects Factory 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 c. Avoid Circular and Complex Bi-Directional References 2. Excessive Memory Use Incorrect Cache Usage Session Caching 3. Classloader-Related Memory Issues Large Classes 4. Out-Of-Memory Errors

Page 13