A common question about IntelliJ is; why pay for it when Eclipse is free. I would argue there are many reasons to use IntelliJ and one is the quality of the code you produce.

I recently ran my default code inspection setting against a reasonable mature project code base. This application is used for enterprise messaging and was developed under eclipse. Is an IDE which makes it easy to run programs which don't compile a good tool to produce quality code... You be the judge.

In many cases the quick fix can be applied to all occurrences so you don't have to fix each one.

Assignment issues: Assignment to 'for' loop parameter.

his inspection reports any instances of assignment a variable declared in a for statement in the body of that statement. It also reports any attempt to increment or decrement the variable. While occasionally intended, this construct can be extremely confusing, and is often the result of a typo.

Class Structure: Class may be an interface.

This inspection reports any concrete or abstract classes which may be simplified to be interfaces. This occurs if the class has no superclass (other than Object), has no fields declared that are not static, final, and public, and has no methods declared that are not public and abstract, and no inner classes that cannot themselves be interfaces.

Class Structure: Empty class.

This inspection reports any empty classes. A class is empty if it doesn't have any fields, methods or constructors. Empty classes are often left over after large changes or refactorings

Class Structure: Field can be local

This inspection searches for redundant class fields that can be replaced with local variables. If all local usages of a field are preceded by assignments to that field, the field can be removed and its usages replaced with local variables.

Class Structure: No-op method in abstract class

This inspection reports any instances of "no-op" methods in abstract classes. It is usually a better design to make such methods abstract themselves, so that classes which inherit the methods will not forget to provide their own implementations.

Class Structure: 'private' method declared 'final'

This inspection reports any instances of methods declared final and private. As private methods cannot be meaningfully overridden, declaring them final is redundant.

Class Structure: 'public' constructor in non-public class

This inspection reports all constructors in non-public classes that are declared public.

Class structure: Singleton

This inspection reports any instances of singleton classes. Singleton classes are declared so that only one instance of the class may ever be instantiated. Singleton classes complicate testing, and their presence may indicate a lack of object-oriented design.

Class structure: 'static' method declared 'final'

This inspection reports any instances of methods declared final and static. As static methods cannot be meaningfully overridden, declaring them final is redundant.

Class structure: 'static', non-'final' field

Code maturity issues: Use of obsolete collection type.

This inspection reports any uses of java.util.Vector or java.util.Hashtable. While still supported, these classes were made obsolete by the JDK1.2 collection classes, and should probably not be used in new development.

Code style issues: expression.equals("literal") rather than "literal".equals(expression)

This inspection reports any instances of calls to .equals() whose arguments are String literals. Some coding standards specify that String literals should be the target of .equals(), rather than argument, thus minimizing NullPointerExceptions.

Control flow issues: Confusing 'else' branch

This inspection reports any instances of confusing else branches. Confusing else branches are branches of if statements whose if branch cannot complete normally and which are followed by other statements. In these cases, the statements following the if statement may be moved into the else branch, for increased clarity.

Control flow issues: 'if' statement with negated condition

This inspection reports any instances of if statements which contain else branches and whose conditions are negated. Flipping the order of the if and else branches will usually increase the clarity of such statements.

Control flow issues: Nested 'switch' statement

This inspection reports all instances of nested switch statements. Nested switch statements may result in extremely confusing code.

Control flow issues: Redundant 'if' statement

This inspection reports instances of if statements which can be simplified to single assignment or return statements. For example:

if(foo())
    {
       return true;
    }
    else
    {
       return false;
    }

return
foo();

Control flow issues: Redundant conditional expression

This inspection reports any instances of conditional expressions of the form condition?true:false or condition?false:true. These expressions may be safely simplified to condition or !condition, respectively.

Control flow issues: 'switch' without 'default' branch

This inspection reports any instances of switch statements that do not contain default labels.

Control flow issues: Unnecessary 'return' statement

This inspection reports on any unnecessary return statements at the end of constructors and methods returning void. These may be safely removed.

Declaration Redundancy: Duplicate throws

This inspection reports duplicate classes in the method throws list. For example:

void f() throws
Exception, Exception {
}

Also, inspection warns if you have declared two exceptions one of which subclasses another. E.g.:

void f() throws IOException, Exception
{
}

Declaration Redundancy: Redundant throws clause

This inspection reports exceptions that are declared in a method's signature but never thrown by the method itself or its implementations/derivatives. Since this inspection requires global code analysis, it is only available in batch inspection mode.

Encapsulation issues: Protected inner class

Error handling: Empty 'catch' block

This inspection reports instances of empty catch blocks. While occasionally intended, this empty catch blocks can make debugging extremely difficult.

Error handling: Non-final field in exception class.

This inspection reports any fields on subclasses of java.lang.Exception which are not declared as final. Data on exception objects should not be modified, as it may result in loss of error context for later debugging and logging.

Error handling: Unused 'catch' parameter.

This inspection reports any catch parameters that are unused in their corresponding blocks. This inspection will not report any catch parameters named "ignore" or "ignored".

Error handling: Prohibited exception caught.

This inspection reports any instances of catch clauses which catch inappropriate exceptions. Some exceptions, for instance java.lang.NullPointerException and java.lang.IllegalMonitorStateException represent programming errors and so should almost certainly not be caught in production code.

Error handling: 'throw' inside 'finally' block.

This inspection reports any instances of throw statements inside of finally blocks. While occasionally intended, such throw statements may mask exceptions thrown, and tremendously complicate debugging.

Error handling: Unused 'catch' parameter.

This inspection reports any catch parameters that are unused in their corresponding blocks. This inspection will not report any catch parameters named "ignore" or "ignored".

Finalization issues: 'finalize()' not declared 'protected'

This inspection reports any implementations of the Object.finalize() method which are not declared protected. finalize() should be declare protected, to prevent it from being explicitly invoked by other classes.

Imports: Import from same package

This inspection reports any import statements which refer to the same package as the containing file. Such imports are unnecessary, and probably the result of incomplete refactorings. Since IDEA can automatically detect and fix such statements with its "Optimize Imports" command, this inspection is mostly useful for off-line reporting on code bases that you don't intend to change.

Inheritance issues: Abstract class which has no concrete subclass.

Inheritance issues: Abstract class without abstract methods.

Inheritance issues: Abstract methods which overrides concrete method

This inspection reports any instances of abstract methods which override concrete methods.

Inheritance issues: Constructor not 'protected' in 'abstract' class.

This inspection reports all instances of constructors in abstract classes that are not declared protected or private.

Inheritance issues: Method is identical to its super method.

This inspection reports any method that has a body and signature that are identical to its super method. Such a method is redundant and probably a coding error.

Initialization issues: Overridden method call in constructor

This inspection reports any calls of overridden methods of the current class within a constructor. Such calls may result in subtle bugs, as the object is not guaranteed to be initialized before the method call occurs.

Initialization issues: Static variable may not be initialized.

Static variables should be final and immutable. If not this suggest a singleton has been used which we strongly discourage.

Initialization issues: 'this' reference escaped in object construction

This inspection reports possible escapes of 'this' during object construction. Escapes occur when 'this' is used as a method argument or the object of an assignment in a constructor or initializer. Such escapes may result in subtle bugs, as the object is now available in a context in which it is not guaranteed to be initialize.

Initialization issues: Unsafe lazy initialization of static field.

Singletons, lazy initialization and code which needs to be thread safe is discouraged.

This inspection reports any instances of static variables being lazily initialized in an non-thread-safe manner. Lazy initialization of static variables should be done in an appropriate synchronization construct, to prevent different threads from performing conflicting initialization. If applicable, non-lazy initialization (e.g., in a static initializer block) is probably a better idea, as the JVM guarantees thread-safety of such initializations.

JSDK 5.0 specific issues and migration aids: 'for' loop replaceable by 'for each'

This inspection reports any instances of for loops which iterate over collections or arrays, and can be replaced with the JDK 5.0 "for each" iteration syntax.

JSDK 5.0 specific issues and migration aids: 'for' loop replaceable by 'for each'

This inspection reports any instances of while loops which iterate over collections, and can be replaced with the JDK 5.0 "for each" iteration syntax.

Memory issues: StringBuffer field

This inspection reports any instances of fields with type java.lang.StringBuffer or java.lang.StringBuilder. StringBuffer fields can grow without limit, and are often the cause of memory leaks.

Memory issues: Zero-length array allocation

This inspection reports on allocations of arrays with known lengths of zero. Since array lengths in Java are non-modifiable, it is almost always possible to share zero-length arrays, rather than repeatedly allocating new zero-length arrays. Such sharing may provide useful optimizations in program runtime or footprint. Note that this inspection does not report zero-length arrays allocated as static final fields, as it is assumed that those arrays are being used to implement array sharing.

Naming conventions: Exception class name does not end with 'Exception'

This inspection reports any instances of exception classes whose names don't end with 'Exception'.

Naming conventions: Non-constant field with upper-case name

This inspection reports any instances of non-static non-final fields whose names are all upper-case. Such fields may cause confusion by breaking a common naming convention, and are often the result of developer error.

Performance issues: Boolean constructor call

This inspection reports any attempt to instantiate a new Boolean object. Constructing new Boolean objects is rarely necessary, and may cause performance problems if done often enough.

Performance issues: Concatenation with empty string

This inspection reports instances of string concatenation where one of the arguments is the empty string. Such concatenation is unnecessary and inefficient, particularly when used as an idiom for formatting non-String objects or primitives into Strings.

Performance issues: Field may be 'static'

This inspection reports any instance variables which may safely be made static. A field may be static if it is declared final, and is initialized with a constant.

Performance issues: Inner class may be 'static'

This inspection reports any inner classes which may safely be made static. An inner class may be static if it doesn't reference its enclosing class instance. A static inner class uses slightly less memory.

Performance issues: Method can be static.

This inspection reports any methods which may safely be made static. A method may be static if it doesn't reference any of its class' non static methods and non static fields and isn't overridden in a sub class.

Performance issues: Unnecessary temporary object in conversion from String

This inspection reports any instances of unnecessary creation of temporary objects when converting from Strings to primitive types. For example, new Integer("3").intValue() would be reported, and could be automatically converted to Integer.valueOf("3").

Probable bugs: Assignment to static field from instance method

This inspection reports any assignments to static fields from within instance methods. While legal, such assignments are tricky to do safely, and are often a result of fields being inadvertently marked static.

Probable bugs: Constant condition & exceptions.

This inspection reports those conditions in the specified inspection scope that are always true or false, as well as possible sources of NullPointerException, where a RuntimeException may be thrown, based on data flow analysis of the code.

Probable bugs: 'equals()' called on array type.

This inspection reports any instances of .equals() being called to compare two arrays. Calling .equals() on an array compares identity and is equivalent to using ==. Use == to see if two references reference the same array and Arrays.equals() to compare the contents of two arrays.

Probable bugs: Infinite recursion

This inspection reports any instances of methods which must either recurse infinitely or throw an exception. Methods reported by this inspection can not return normally.

Probable bugs: Mismatched query and update of collection

This inspection reports instances of collection fields or variables whose contents are either queried and not updated, or updated and not queried. Such mismatched queries and updates are pointless, and may indicate either dead code or a typographical error.

Probable bugs: Non-final field reference in 'equals()'

This inspection reports any implementations of equals() which access non-final variables. Such access may result in equals() returning different results at different points in an object's lifecycle, which may in turn cause problems when using the standard Collections classes.

Probable bugs: Result of object allocation ignored.

This inspection reports any instances of object allocation where the object allocated ignored. Such allocation expressions are legal Java, but are usually either inadvertent, or evidence of a very odd object initialization strategy.

Probable bugs: String comparison using '==', instead of 'equals()'

This inspection reports any use of == to test for String equality, rather than the ".equals()" method.

Threading issues: Field accessed in both synchronized and unsynchronized contexts.

This inspection reports any instances of non-final fields which are accessed in both synchronized and unsynchronized contexts. Accesses in constructors an initializers are ignored for purposes of this inspection. Such "partially synchronized" access is often the result of a coding oversight, and may result in unexpectedly inconsistent data structures.

Threading issues: Nested 'synchronized' statement

This inspection reports all instances of nested synchronized statements. Nested synchronized statements are either useless (if the lock objects are identical) or prone to deadlock.

Threading issues: Non-private field accessed in synchronized context

This inspection reports any instances of non-final, non-private fields which are accessed in a synchronized context. A non-private field cannot be guaranteed to always be accessed in a synchronized manner, and such "partially synchronized" access may result in unexpectedly inconsistent data structures. Accesses in constructors an initializers are ignored for purposes of this inspection.

Threading issues: 'notify()' or 'notifyAll()' without corresponding state change.

This inspection reports any instances of .notify() or .notifyAll() being called without any detectable state change occuring. Normally, .notify() and .notifyAll() are used to inform other threads that a state change has occured. That state change should occur in a synchronized context that contains the .notify() or .notifyAll() call, and prior to the call. While not having such a state change isn't necessarily incorrect, it is certainly worth examining.

Threading issues: Synchronization on a non-final field.

This inspection reports instances of synchronized statements where the lock expression is a non-final field. Such statements are unlikely to have useful semantics, as different threads may be locking on different objects even when operating on the same object.

Threading issues: Volatile long or double field

This inspection reports fields of type long or double which are declared as volatile. While Java specifies that reads and writes from such fields are atomic, many JVM's have violated this specification. Unless you are certain of your JVM, it is better to synchronized access to such fields rather than declare them volatile.

Probable bugs: Unused assignment.

This inspection points out the cases where a variable value is never used after its assignment, i.e.:

Visibility issues: Inner class field hides outer class field

This inspection reports any instances of inner class variables being named identically to member variables of a containing class. Such a variable name may be confusing.

Navigation

Getting Started

Essence Documentation

Download

Contact

Eclipse vs IntelliJ and code quality.

Assignment issues: Assignment to 'for' loop parameter.

Class Structure: Class may be an interface.

Class Structure: Empty class.

Class Structure: Field can be local

Class Structure: No-op method in abstract class

Class Structure: 'private' method declared 'final'

Class Structure: 'public' constructor in non-public class

Class structure: Singleton

Class structure: 'static' method declared 'final'

Class structure: 'static', non-'final' field

Code maturity issues: Use of obsolete collection type.

Code style issues: expression.equals("literal") rather than "literal".equals(expression)

Control flow issues: Confusing 'else' branch

Control flow issues: 'if' statement with negated condition

Control flow issues: Nested 'switch' statement

Control flow issues: Redundant 'if' statement

Control flow issues: Redundant conditional expression

Control flow issues: 'switch' without 'default' branch

Control flow issues: Unnecessary 'return' statement

Declaration Redundancy: Duplicate throws

Declaration Redundancy: Redundant throws clause

Encapsulation issues: Protected inner class

Error handling: Empty 'catch' block

Error handling: Non-final field in exception class.

Error handling: Unused 'catch' parameter.

Error handling: Prohibited exception caught.

Error handling: 'throw' inside 'finally' block.

Error handling: Unused 'catch' parameter.

Finalization issues: 'finalize()' not declared 'protected'

Imports: Import from same package

Inheritance issues: Abstract class which has no concrete subclass.

Inheritance issues: Abstract class without abstract methods.

Inheritance issues: Abstract methods which overrides concrete method

Inheritance issues: Constructor not 'protected' in 'abstract' class.

Inheritance issues: Method is identical to its super method.

Initialization issues: Overridden method call in constructor

Initialization issues: Static variable may not be initialized.

Initialization issues: 'this' reference escaped in object construction

Initialization issues: Unsafe lazy initialization of static field.

JSDK 5.0 specific issues and migration aids: 'for' loop replaceable by 'for each'

JSDK 5.0 specific issues and migration aids: 'for' loop replaceable by 'for each'

Memory issues: StringBuffer field

Memory issues: Zero-length array allocation

Naming conventions: Exception class name does not end with 'Exception'

Naming conventions: Non-constant field with upper-case name

Performance issues: Boolean constructor call

Performance issues: Concatenation with empty string

Performance issues: Field may be 'static'

Performance issues: Inner class may be 'static'

Performance issues: Method can be static.

Performance issues: Unnecessary temporary object in conversion from String

Probable bugs: Assignment to static field from instance method

Probable bugs: Constant condition & exceptions.

Probable bugs: 'equals()' called on array type.

Probable bugs: Infinite recursion

Probable bugs: Mismatched query and update of collection

Probable bugs: Non-final field reference in 'equals()'

Probable bugs: Result of object allocation ignored.

Probable bugs: String comparison using '==', instead of 'equals()'

Threading issues: Field accessed in both synchronized and unsynchronized contexts.

Threading issues: Nested 'synchronized' statement

Threading issues: Non-private field accessed in synchronized context

Threading issues: 'notify()' or 'notifyAll()' without corresponding state change.

Threading issues: Synchronization on a non-final field.

Threading issues: Volatile long or double field

Probable bugs: Unused assignment.

Visibility issues: Inner class field hides outer class field