Hi, I've just imported v2 into a local sonarqube [1] . According to the default rules there are about 4K isssues ranging from (Bug to Code Smell and from Blocker to Info).
I'm the author of 2 (unused private constructor). Should I raise a Jira issue for each type of finding (see Top 100 below)? Should fixes be made against master? Would it make sense to use [2]? -j [1] https://www.sonarqube.org/ [2] https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis ---- 8< ---- (Java) Sections of code should not be commented out 359 (Java) Modifiers should be declared in the correct order 297 (CSS) Selectors of lower specificity should come before overriding selectors of higher specificity 235 (Java) Inheritance tree of classes should not be too deep 224 (Java) Track uses of "TODO" tags 176 (Java) Source files should not have any duplicated blocks 162 (Java) Methods should not be empty 154 (Java) Local variables should not be declared and then immediately returned or thrown 134 (Java) Generic exceptions should never be thrown 132 (Java) Local variables should not shadow class fields 108 (Java) Class names should comply with a naming convention 103 (Java) String literals should not be duplicated 96 (Java) "@Deprecated" code should not be used 81 (Java) Cognitive Complexity of methods should not be too high 81 (Java) Utility classes should not have public constructors 77 (Java) "throws" declarations should not be superfluous 75 (Java) Deprecated code should be removed 72 (Java) Static non-final field names should comply with a naming convention 70 (Java) Unused method parameters should be removed 64 (Java) Class variable fields should not have public accessibility 60 (Java) Fields in a "Serializable" class should either be transient or serializable 57 (Java) "public static" fields should be constant 55 (Java) Declarations should use Java collection interfaces such as "List" rather than specific implementation classes such as "LinkedList" 52 (Java) Class names should not shadow interfaces or superclasses 46 (Java) Local variable and method parameter names should comply with a naming convention 45 (Java) Parsing should be used to convert "Strings" to primitives 39 (Java) Standard outputs should not be used directly to log anything 39 (Java) "Preconditions" and logging arguments should not require evaluation 36 (Java) Empty arrays and collections should be returned instead of null 36 (Java) Generic wildcard types should not be used in return parameters 35 (Java) Null pointers should not be dereferenced 35 (Java) Nested code blocks should not be used 34 (Java) Null checks should not be used with "instanceof" 34 (Java) Unused "private" fields should be removed 33 (Java) TestCases should contain tests 32 (Java) "static" members should be accessed statically 31 (Java) Collapsible "if" statements should be merged 30 (Java) Empty statements should be removed 27 (Java) Mutable fields should not be "public static" 27 (Java) Useless imports should be removed 27 (Java) Return of boolean expressions should not be wrapped into an "if-then-else" statement 25 (Java) Unused local variables should be removed 24 (Java) Loops should not contain more than a single "break" or "continue" statement 23 (Java) Synchronized classes Vector, Hashtable, Stack and StringBuffer should not be used 23 (Java) Deprecated elements should have both the annotation and the Javadoc tag 22 (Java) "entrySet()" should be iterated when both the key and value are needed 21 (Java) Dead stores should be removed 20 (Java) Methods should not have identical implementations 20 (Java) Assignments should not be made from within sub-expressions 19 (Java) Collection.isEmpty() should be used to test for emptiness 19 (Java) Jump statements should not be redundant 19 (Java) Printf-style format strings should be used correctly 19 (Java) Method names should comply with a naming convention 18 (Java) String function use should be optimized for single characters 18 (Java) Constant names should comply with a naming convention 17 (Java) Constants should not be defined in interfaces 17 (Java) "switch" statements should have at least 3 "case" clauses 16 (Java) Methods should not return constants 16 (Java) Nested "enum"s should not be declared static 16 (Java) Tests should not be ignored 16 (Java) Arrays should not be created for varargs parameters 15 (Java) Boolean expressions should not be gratuitous 14 (Java) Methods should not have too many parameters 14 (Java) Track uses of "FIXME" tags 14 (Java) Only static class initializers should be used 13 (Java) Overriding methods should do more than simply call the same method in the super class 13 (Java) Redundant casts should not be used 13 (Java) Nested blocks of code should not be left empty 12 (Java) Ternary operators should not be nested 12 (Java) "switch" statements should have "default" clauses 11 (Java) Abstract methods should not be redundant 11 (Java) "private" methods called only by inner classes should be moved to those classes 10 (Java) Field names should comply with a naming convention 10 (Java) Subclasses that add fields should override "equals" 10 (Java) Constructors should not be used to instantiate "String", "BigInteger", "BigDecimal" and primitive-wrapper classes 9 (Java) Double Brace Initialization should not be used 9 (Java) Resources should be closed 9 (Java) Unused "private" methods should be removed 9 (Java) Classes named like "Exception" should extend "Exception" or a subclass 8 (Java) Credentials should not be hard-coded 8 (Java) Package names should comply with a naming convention 8 (Java) Public constants and fields initialized at declaration should be "static final" rather than merely "final" 8 (Java) Exceptions should not be thrown from servlet methods 7 (CSS) Selectors should not be duplicated 6 (Java) "equals(Object obj)" should be overridden along with the "compareTo(T obj)" method 6 (Java) A field should not duplicate the name of its containing class 6 (Java) Boolean literals should not be redundant 6 (Java) Methods returns should not be invariant 6 (Java) Try-catch blocks should not be nested 6 (Java) Unused type parameters should be removed 6 (Java) Array designators "[]" should be on the type, not the variable 5 (Java) Child class fields should not shadow parent class fields 5 (Java) Instance methods should not write to "static" fields 5 (Java) Methods and field names should not be the same or differ only by capitalization 5 (Java) Optional value should only be accessed after calling isPresent() 5 (Java) Private fields only used as local variables in methods should become local variables 5 (Java) Throwable and Error should not be caught 5 (JavaScript) Unused local variables and functions should be removed 5 (Java) "InterruptedException" should not be ignored 4 (Java) Null should not be returned from a "Boolean" method 4 Kühne + Nagel (AG & Co.) KG Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878. Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Tom Ban, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, Lars Wedel, Matthias Weiner. Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze. Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
