1. 程式人生 > >sonarqube基礎:掃描規則:1: Sonar way之Java版

sonarqube基礎:掃描規則:1: Sonar way之Java版

SonarQube內嵌了Sonar way的掃描規則,不同語言具有不同版本,比如C#/Java/Javascript等,預設從三個維度對規則進行劃分,這篇文章以Sonarqube 5.6.5版本為例,將Java部分的相關的規則進行簡單整理。

規則匯出

使用下圖的back up功能可將相關的規則匯出成xml檔案格式
在這裡插入圖片描述

規則狀況

此版本的Java的Sonar way共有規則254條,相關的數量如下:

總類 規則數量
缺陷(Bug) 75
安全(Vulnerability) 20
改善(Code Smell) 159

缺陷

缺陷相關的規則
“.equals()” should not be used to test the values of “Atomic” classes
“@NonNull” values should not be set to null
“BigDecimal(double)” should not be used
“Calendars” and “DateFormats” should not be static
“Cloneables” should implement “clone”
“compareTo” should not return “Integer.MIN_VALUE”
“Double.longBitsToDouble” should not be used for “int”
“equals(Object obj)” and “hashCode()” should be overridden in pairs
“equals(Object obj)” should be overridden along with the “compareTo(T obj)” method
“equals(Object obj)” should test argument type
“Externalizable” classes should have a no-arguments constructor
“hashCode” and “toString” should not be called on array instances
“instanceof” operators that always return “true” or “false” should be removed
“InterruptedException” should not be ignored
“Iterator.hasNext()” should not call “Iterator.next()”
“Object.wait(…)” and “Condition.await(…)” should be called inside a “while” loop
“Object.wait(…)” should never be called on objects that implement “java.util.concurrent.locks.Condition”
“PreparedStatement” and “ResultSet” methods should be called with valid indices
“read” and “readLine” return values should be used
“return” statements should not occur in “finally” blocks
“runFinalizersOnExit” should not be called
“ScheduledThreadPoolExecutor” should not have 0 core threads
“Serializable” inner classes of non-serializable classes should be “static”
“SingleConnectionFactory” instances should be set to “reconnectOnException”
“toString()” and “clone()” methods should not return null
“wait(…)”, “notify()” and “notifyAll()” methods should only be called when a lock is obviously held on an object
A “for” loop update clause should move the counter in the right direction
Assertions should be complete
Assignments should not be made from within sub-expressions
Classes should not be compared by name
Collections should not be passed as arguments to their own methods
Conditions should not unconditionally evaluate to “TRUE” or to “FALSE”
Custom serialization method signatures should meet requirements
Default EJB interceptors should be declared in “ejb-jar.xml”
Dissimilar primitive wrappers should not be used with the ternary operator without explicit casting
Fields in a “Serializable” class should either be transient or serializable
Floating point numbers should not be tested for equality
Identical expressions should not be used on both sides of a binary operator
IllegalMonitorStateException should not be caught
Inappropriate “Collection” calls should not be made
Inappropriate regular expressions should not be used
Instance methods should not write to “static” fields
Ints and longs should not be shifted by more than their number of bits-1
Invalid “Date” values should not be used
JUnit assertions should not be used in “run” methods
JUnit framework methods should be declared properly
JUnit test cases should call super methods
Locks should be released
Loop conditions should be true at least once
Loops should not be infinite
Math operands should be cast before assignment
Methods “wait(…)”, “notify()” and “notifyAll()” should never be called on Thread instances
Methods should not be named “hashcode” or “equal”
Multiline blocks should be enclosed in curly braces
Neither “Math.abs” nor negation should be used on numbers that could be “MIN_VALUE”
Non-public methods should not be “@Transactional”
Non-serializable classes should not be written
Non-serializable objects should not be stored in “HttpSessions”
Null pointers should not be dereferenced
Objects should not be created to be dropped immediately without being used
Printf-style format strings should not lead to unexpected behavior at runtime
Raw byte values should not be used in bitwise operations in combination with shifts
Reflection should not be used to check non-runtime annotations
Related “if/else if” statements should not have the same condition
Relational operators should be used in “for” loop termination conditions
Resources should be closed
Servlets should not have mutable instance fields
Short-circuit logic should be used in boolean contexts
Silly equality checks should not be made
super.finalize() should be called at the end of Object.finalize() implementations
Synchronization should not be based on Strings or boxed primitives
The non-serializable super class of a “Serializable” class should have a no-argument constructor
The value returned from a stream read should be checked
Thread.run() and Runnable.run() should not be called directly
Values should not be uselessly incremented

安全

脆弱性相關的規則
“ConcurrentLinkedQueue.size()” should not be used
“enum” fields should not be publicly mutable
“File.createTempFile” should not be used to create a directory
“HttpServletRequest.getRequestedSessionId()” should not be used
“public static” fields should be constant
“static final” arrays should be “private”
“wait(…)” should be used instead of “Thread.sleep(…)” when a lock is held
Cookies should be “secure”
Credentials should not be hard-coded
Cryptographic RSA algorithms should always incorporate OAEP (Optimal Asymmetric Encryption Padding)
Exceptions should not be thrown from servlet methods
Generic exceptions should never be thrown
IP addresses should not be hardcoded
Mutable fields should not be “public static”
The Object.finalize() method should not be called
Throwable and Error should not be caught
Throwable.printStackTrace(…) should not be called
Values passed to SQL commands should be sanitized
Web applications should not have a “main” method
Web applications should use validation filters

改善

改善相關的規則
“@Override” annotation should be used on any method overriding (since Java 5) or implementing (since Java 6) another one
“assert” should only be used with boolean variables
“catch” clauses should do more than rethrow
“clone” should not be overridden
“compareTo” results should not be checked for specific values
“DateUtils.truncate” from Apache Commons Lang library should not be used
“entrySet()” should be iterated when both the key and value are needed
“finalize” should not set fields to “null”
“FIXME” tags should be handled
“for” loop incrementers should modify the variable being tested in the loop’s stop condition
“for” loop stop conditions should be invariant
“indexOf” checks should not be for positive numbers
“indexOf” checks should use a start position
“Iterator.next()” methods should throw “NoSuchElementException”
“Lock” objects should not be “synchronized”
“Object.finalize()” should remain protected (versus public) when overriding
“private” methods called only by inner classes should be moved to those classes
“readObject” should not be “synchronized”
“readResolve” methods should be inheritable
“ResultSet.isLast()” should not be used
“static” members should be accessed statically
“StringBuilder” and “StringBuffer” should not be instantiated with a character
“switch case” clauses should not have too many lines
“switch” statements should end with a “default” clause
“switch” statements should have at least 3 “case” clauses
“switch” statements should not contain non-case labels
“switch” statements should not have too many “case” clauses
“Thread.sleep” should not be used in tests
“Threads” should not be used where “Runnables” are expected
“TODO” tags should be handled
“toString()” should never be called on a String object
“URL.hashCode” and “URL.equals” should be avoided
@FunctionalInterface annotation should be used to flag Single Abstract Method interfaces
A “while” loop should be used instead of a “for” loop
A field should not duplicate the name of its containing class
Abstract classes without fields should be converted to interfaces
Abstract methods should not be redundant
Annotation repetitions should not be wrapped
Anonymous inner classes containing only one method should become lambdas
Array designators “[]” should be located after the type in method signatures
Array designators “[]” should be on the type, not the variable
Boxing and unboxing should not be immediately reversed
Branches should have sufficient coverage by unit tests
Case insensitive string comparisons should be made without intermediate upper or lower casing
Catches should be combined
Child class members should not shadow parent class members
Child class methods named for parent class methods should be overrides
Class names should comply with a naming convention
Class names should not shadow interfaces or superclasses
Class variable fields should not have public accessibility
Classes extending java.lang.Thread should override the “run” method
Classes from “sun.*” packages should not be used
Classes named like “Exception” should extend “Exception” or a subclass
Classes should not be empty
Classes that override “clone” should be “Cloneable” and call “super.clone()”
Classes with only “static” methods should not be instantiated
Collapsible “if” statements should be merged
Collection.isEmpty() should be used to test for emptiness
Collections.emptyList(), emptyMap() and emptySet() should be used instead of Collections.EMPTY_LIST, EMPTY_MAP and EMPTY_SET
Constant names should comply with a naming convention
Constants should not be defined in interfaces
Constructor injection should be used instead of field injection
Control flow statements “if”, “for”, “while”, “switch” and “try” should not be nested too deeply
Dead stores should be removed
Declarations should use Java collection interfaces such as “List” rather than specific implementation classes such as “LinkedList”
Dependencies should not have “system” scope
Deprecated “${pom}” properties should not be used
Deprecated code should be removed eventually
Deprecated elements should have both the annotation and the Javadoc tag
Empty arrays and collections should be returned instead of null
Enumeration should not be implemented
Exception classes should be immutable
Exception handlers should preserve the original exception
Exception types should not be tested using “instanceof” in catch blocks
Exceptions should not be thrown in finally blocks
Execution of the Garbage Collector should be triggered only by the JVM
Exit methods should not be called
Expressions should not be too complex
Field names should comply with a naming convention
Fields in non-serializable classes should not be “transient”
Future keywords should not be used as names
Generic wildcard types should not be used in return parameters
Inheritance tree of classes should not be too deep
Inner class calls to super class methods should be unambiguous
Interface names should comply with a naming convention
JUnit rules should be used
Labels should not be used
Lambdas and anonymous classes should not have too many lines
Lambdas should be replaced with method references
Lamdbas containing only one statement should not nest this statement in a block
Literal boolean values should not be used in condition expressions
Local variable and method parameter names should comply with a naming convention
Local Variables should not be declared and then immediately returned or thrown
Local variables should not shadow class fields
Long suffix “L” should be upper case
Loops should not contain more than a single “break” or “continue” statement
Maps with keys that are enum values should be replaced with EnumMap
Method names should comply with a naming convention
Method overrides should not change contracts
Method parameters, caught exceptions and foreach variables should not be reassigned
Methods and field names should not be the same or differ only by capitalization
Methods named “equals” should override Object.equals(Object)
Methods of “Random” that return floating point values should not be used in random integer generation
Methods should not be empty
Methods should not be too complex
Methods should not have too many parameters
Modifiers should be declared in the correct order
Multiple variables should not be declared on the same line
Nested "enum"s should not be declared static
Nested blocks of code should not be left empty
Nested code blocks should not be used
Non-constructor methods should not have the same name as the enclosing class
Null should not be returned from a “Boolean” method
Objects should not be created only to “getClass”
Only static class initializers should be used
Overriding methods should do more than simply call the same method in the super class
Package declaration should match source file directory
Package names should comply with a naming convention
Parentheses should be removed from a single lambda input parameter when its type is inferred
Parsing should be used to convert “Strings” to primitives
Primitive wrappers should not be instantiated only for “toString” or “compareTo” calls
Primitives should not be boxed just for “String” conversion
Public constants and fields initialized at declaration should be “static final” rather than merely “final”
Public methods should throw at most one checked exception
Redundant casts should not be used
Return of boolean expressions should not be wrapped into an “if-then-else” statement
Sections of code should not be “commented out”
Silly bit operations should not be performed
Silly math should not be performed
Source files should not have any duplicated blocks
Standard outputs should not be used directly to log anything
Statements should be on separate lines
Static non-final field names should comply with a naming convention
String function use should be optimized for single characters
String literals should not be duplicated
String.valueOf() should not be appended to a String
Strings literals should be placed on the left side when checking for equality
Subclasses that add fields should override “equals”
Switch cases should end with an unconditional “break” statement
Synchronized classes Vector, Hashtable, Stack and StringBuffer should not be used
TestCases should contain tests
The default unnamed package should not be used
The diamond operator ("<>") should be used
The members of an interface declaration or class should appear in a pre-defined order
The Object.finalize() method should not be overriden
The signature of “finalize()” should match that of “Object.finalize()”
Throws declarations should not be superfluous
Try-catch blocks should not be nested
Try-with-resources should be used
Type parameter names should comply with a naming convention
Unused labels should be removed
Unused local variables should be removed
Unused method parameters should be removed
Unused private fields should be removed
Unused private method should be removed
Unused type parameters should be removed
Useless imports should be removed
Useless parentheses around expressions should be removed to prevent any misunderstanding
Utility classes should not have public constructors

總結

Sonar預設從Bug/Vulnerability/Code Smell維度進行劃分,同時不同維度的掃描規則的等級也有所不同,比如Major或者Minor,在實際使用的時候可以根據具體情況進行調整,在接下來的文章中將會介紹如何定製生成sonar的profile。