TIOBE - Java Coding Standard

Coding Rules

Name	Checked	Synopsis
Basic1		Avoid empty catch blocks
Basic2		Avoid empty 'if' statements
Basic3		Avoid empty 'while' statements
Basic4		Avoid empty try blocks
Basic5		Avoid empty finally blocks
Basic6		Avoid empty switch statements
Basic7		Avoid modifying an outer loop incrementer in an inner loop for update expression
Basic8		This for loop could be simplified to a while loop
Basic9		Avoid unnecessary temporaries when converting primitives to Strings
Basic10		Ensure you override both equals() and hashCode()
Basic11		Double checked locking is not thread safe in Java
Basic12		Avoid returning from a finally block
Basic13		Avoid empty synchronized blocks
Basic14		Avoid unnecessary return statements
Basic15		Empty static initializer was found
Basic16		Do not use 'if' statements that are always true or always false
Basic17		An empty statement (semicolon) not part of a loop
Basic18		Avoid instantiating Boolean objects; reference Boolean.TRUE or Boolean.FALSE
Basic19		Unnecessary modifier used
Basic20		These nested if statements could be combined
Basic21		Overriding method merely calls super
Basic22		This usage of the Collection.toArray() method will throw a ClassCastException
Basic23		Avoid creating BigDecimal with a decimal (float/double) literal. Use a String literal
Basic24		An operation on an Immutable object (BigDecimal or BigInteger) won't change the object itself
Basic25		The null check here is misplaced; if the variable is null there'll be a NullPointerException
Basic26		Invoke equals() on the object you've already ensured is not null
Basic27		Avoid using ThreadGroup; it is not thread safe
Basic28		Method call on object which may be null
Basic29		Don't create instances of already existing BigInteger and BigDecimal (ZERO, ONE, TEN)
Basic30		Do not start a literal by 0 unless it's an octal value
Basic31		Replace for loop by for each loop
Basic32		Use @Override annotation if applicable
Basic33		Merge identical catch branches
Basic34		Don't use unclear do/while loops
Basic100		Each variable should have an initializer.
Basic101		Use standard brace style.
Basic102		Avoid implicit allocation of objects
Basic103		Don't modify control variables within a for block
CloneImplementation1		Object clone() should be implemented with super.clone()
CloneImplementation2		clone() method should throw CloneNotSupportedException
CloneImplementation3		clone() method should be implemented only if implementing Cloneable interface
CloneImplementation4		Clone method should be public
CloneImplementation5		Clone method return type should match class name
CodeSize1		Avoid complex methods
CodeSize2		Avoid really long methods
CodeSize3		Avoid really long parameter lists
CodeSize4		Avoid really long classes
CodeSize5		Avoid complex code
CodeSize6		This class has too many public methods and attributes
CodeSize7		Too many fields
CodeSize8		Avoid large methods
CodeSize9		Avoid long type definitions
CodeSize10		Avoid complex constructors
CodeSize100		Avoid long files
Comments100		Every file should have a copyright statement at the top.
Comments101		Use standard Java annotations.
Comments102		Use one annotation per line.
Comments103		Use TODO comments.
Comments104		Each class should be preceded by JavaDoc comments.
Controversial1		Avoid unnecessary constructors - the compiler will generate these for you
Controversial2		Assigning an Object to null is a code smell. Consider refactoring
Controversial3		A method should have only one exit point, and that should be the last statement in the method
Controversial4		Avoid modifiers which are implied by the context
Controversial5		Avoid assignments in operands
Controversial6		Each class should declare at least one constructor
Controversial7		Avoid importing anything from the 'sun.*' packages
Controversial8		Suspicious decimal characters following octal escape in string literal
Controversial9		It is a good practice to call super() in a constructor
Controversial10		This statement may have some unnecessary parentheses
Controversial11		If a field is only used by one method, consider making it a local variable
Controversial12		Use explicit scoping instead of the default package private level
Controversial12		Use explicit scoping instead of the default package private level
Controversial13		Use bitwise inversion to invert boolean values
Controversial14		Make sure variable assignment has been performed correctly
Coupling1		High amount of different objects as members denotes a high coupling
Coupling2		A high number of imports can indicate a high degree of coupling within an object
Coupling3		Avoid using implementation types; use the interface instead
Design1		Classes with only static methods should have a private constructor
Design2		Avoid unnecessary if..then..else statements when returning a boolean
Design3		Avoid unnecessary comparisons in boolean expressions
Design4		Switch statements should have a default label
Design5		Deeply nested if..then statements are hard to read
Design6		Avoid reassigning parameters
Design7		A high ratio of statements to labels in a switch statement. Consider refactoring
Design8		Don't call overridable methods during object construction
Design9		Avoid instantiation through private constructors from outside of the constructor's class
Design10		This final field could be made static
Design11		Ensure that resources are closed after use
Design12		Non-static initializers are confusing
Design13		The default label should be the last label in a switch statement
Design14		A non-case label was present in a switch statement
Design15		This call to Collection.toArray() may be optimizable
Design16		Avoid equality comparisons with Double.NaN
Design17		Avoid using equals() to compare against null
Design18		Avoid if (x != y) ..; else ..;
Design19		Avoid instantiating an object just to call getClass() on it; use the .class public member instead
Design20		Avoid idempotent operations (like assigning a variable to itself)
Design21		When instantiating a SimpleDateFormat object, specify a Locale
Design22		Declare private fields final, if possible
Design23		When doing a String.toLowerCase()/toUpperCase() call, use a Locale
Design24		Avoid protected fields in a final class. Change to private or package access
Design25		Possible unsafe assignment to a non-final static field in a constructor
Design26		Class cannot be instantiated and does not provide any static methods or fields
Design27		Use block level rather than method level synchronization
Design28		A switch statement does not contain a break
Design29		Call Thread.notifyAll() rather than Thread.notify()
Design30		An instanceof check is being performed on the caught exception. Create a separate catch clause for this exception type
Design31		This abstract class does not have any abstract methods
Design32		No need to check for null before an instanceof
Design33		Use equals() to compare object references
Design34		Position literals first in String comparisons
Design35		Consider simply returning values instead of storing it in a local variable
Design36		Singleton is not thread safe
Design37		Document empty method
Design38		Document empty constructor
Design39		An Interface should be used only to model a behaviour; consider converting this to a class
Design40		Static java.text.Format objects should be accessed in a synchronized manner
Design41		Caught exception is rethrown, original stack trace may be lost
Design42		Substitute calls to size() == 0 (or size() != 0) with calls to isEmpty()
Design43		Declare members privately
Design44		Never initialize a final field to null
Design45		Avoid overloading the getInstance method
Design100		The scope of local variables should be kept to a minimum.
Design101		Classes with only private constructors should be declared as final
Finalizer1		Avoid empty finalize methods
Finalizer2		Finalize should do something besides just calling super.finalize()
Finalizer3		Finalize methods should not be overloaded
Finalizer4		Last statement in finalize method should be a call to super.finalize()
Finalizer5		If you override finalize(), make it protected
Finalizer6		Avoid calling finalize() explicitly
Finalizer100		Don't use finalizers.
Import101		Order import statements.
ImportStatement1		Avoid duplicate imports
ImportStatement2		Avoid importing anything from the package 'java.lang'
ImportStatement3		Avoid unused imports
ImportStatement4		No need to import a type that lives in the same package
ImportStatement100		Fully qualify imports.
ImportStatement101		Order Import Statements.
JUnit1		You have a suite() method that is not both public and static, so JUnit won't call it to get your TestSuite. Is that what you wanted to do?
JUnit2		You may have misspelled a JUnit framework method (setUp or tearDown)
JUnit3		JUnit assertions should include a message
JUnit4		JUnit tests should include assert() or fail()
JUnit5		This class name ends with 'Test' but contains no test cases
JUnit6		assertTrue(true) or similar statements are unnecessary
JUnit7		Use assertEquals(x, y) instead of assertTrue(x.equals(y))
JUnit8		Use assertSame(x, y) instead of assertTrue(x==y), or assertNotSame(x,y) vs assertFalse(x==y)
JUnit9		Use assertNull(x) instead of assertTrue(x==null), or assertNotNull(x) vs assertFalse(x==null)
JUnit10		assertTrue(!expr) can be replaced by assertFalse(expr)
JavaLogging1		Class contains more than one logger.
JavaLogging2		The Logger variable declaration does not contain the static and final modifiers
JavaLogging3		System.out.print is used
JavaLogging4		Avoid printStackTrace(); use a logger call instead.
Multithreading1		Avoid storing MessageDigest in a field that can be accessed by multiple threads
Naming1		Avoid variables with short names
Naming2		Avoid excessively long variable names
Naming3		Avoid using short method names
Naming4		Use naming conventions for variables
Naming5		Method name does not begin with a lower case character
Naming6		Class names should begin with an uppercase character
Naming7		Abstract classes should be named 'AbstractXXX'
Naming8		Avoid using dollar signs in variable/method/class/interface names
Naming9		Classes should not have non-constructor methods with the same name as the class
Naming10		The method name and return type are suspiciously close to hashCode()
Naming11		The field name indicates a constant but its modifiers do not
Naming12		The method name and parameter number are suspiciously close to equals(Object)
Naming13		It is somewhat confusing to have a field name matching the declaring class name
Naming14		It is somewhat confusing to have a field name with the same name as a method
Naming15		Don't define methods with the same name as the class name
Naming16		All classes and interfaces must belong to a named package
Naming17		Package name contains upper case characters
Naming18		Avoid naming non-fields with a member-like prefix
Naming101		Treat acronyms as words
Optimization1		Local variables assigned only once can be declared final
Optimization2		A method argument that is never assigned can be declared final
Optimization3		Avoid instantiating new objects inside loops
Optimization4		Use ArrayList instead of Vector
Optimization5		This call to String.startsWith can be rewritten using String.charAt(0)
Optimization6		Prefer StringBuffer over += for concatenating strings
Optimization7		Use asList instead of tight loops
Optimization8		System.arrayCopy is more efficient
Optimization9		Unnecessary wrapper object creation
Optimization10		Avoid using FileStream
Optimization11		Avoid double brace initialization
Optimization12		Avoid creating Calendar objects
Optimization100		Declare JAXBcontext variables as static.
Security1		Do not use hard coded values for cryptographic operations
Security2		Do not use hard coded initialization vector in cryptographic operations
SecurityCodeGuidelines1		Don't return an internal array directly.
SecurityCodeGuidelines2		User-supplied arrays should be copied before use
StrictException1		A catch statement should never catch throwable since it includes errors
StrictException2		A method/constructor shouldn't explicitly throw java.lang.Exception
StrictException3		Avoid using exceptions as flow control
StrictException4		Avoid catching NullPointerException; consider removing the cause of the NPE
StrictException5		Avoid throwing raw exception types
StrictException6		Avoid throwing null pointer exceptions
StrictException7		A catch statement that catches an exception only to rethrow it should be avoided
StrictException8		Use the try-with-resources statement to ensure resources are closed
StrictException100		Don't ignore exceptions.
StrictException101		Don't catch generic exceptions.
StrictException102		Exception classes should only contain final fields
StringandStringBuffer1		Don't use duplicate String literals; use constants instead
StringandStringBuffer2		Avoid instantiating String objects; this is usually unnecessary
StringandStringBuffer3		Avoid calling toString() on String objects; this is unnecessary
StringandStringBuffer4		Avoid concatenating nonliterals in a StringBuffer constructor or append()
StringandStringBuffer5		Using equalsIgnoreCase() is cleaner than using toUpperCase/toLowerCase().equals()
StringandStringBuffer6		This is an inefficient use of StringBuffer.toString; call StringBuffer.length instead
StringandStringBuffer7		Avoid appending characters as strings in StringBuffer.append
StringandStringBuffer8		Combine StringBuffer.append calls, if possible
StringandStringBuffer9		String.indexOf(char) is faster than String.indexOf(String)
StringandStringBuffer10		String.trim().length()==0 is an inefficient way to validate an empty String
StringandStringBuffer11		Initialize objects of StringBuffer with a proper size
StringandStringBuffer12		No need to call String.valueOf to append to a string
StringandStringBuffer13		Do not instantiate a StringBuffer with a char
StringandStringBuffer14		Use equals() to compare String objects
Style100		Don't use tabs.
Style101		Indent properly.
Style102		Limit line length.
Style102		Limit line length
TypeResolution1		Avoid using implementation types; use the interface instead
TypeResolution2		clone() method should be implemented only if implementing Cloneable interface
TypeResolution2		Use the diamond operator to let the type be inferred automatically
TypeResolution2		Use the diamond operator to let the type be inferred automatically
TypeResolution2		Use the try-with-resources statement to ensure resources are closed
TypeResolution2		Use the diamond operator to let the type be inferred automatically
TypeResolution3		Use the diamond operator to let the type be inferred automatically
TypeResolution4		Use short array initializers without repeated type information
UnusedCode1		Avoid unused private fields
UnusedCode2		Avoid unused local variables
UnusedCode3		Avoid unused private methods
UnusedCode4		Avoid unused {0} parameters
UnusedCode5		Avoid unused assignments
UnusedCode100		Empty statements (standalone ';' semicolons) are not allowed
test		test