Hi Jörg, I've used sonarqube in the past, but only to find myself using the reports on some key metrics such as 'Lines of Code'. Version 5.6.6 had a pretty chart that could render an overview of the modules with colored rectangles representing lines of code by their rectangle's sizes.
Other than that I find that sonarqube is a great tool for code reviewing, but still needs a human brain to actually go through the rule violations and decide whether a Jira issue should be filed or not. So having reports automated, that produce some interesting metrics seems a plus for me. But I'd suggest not to create Jira issues without a thorough code-review. Cheers Andi On 2018/12/19 15:44:37, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <joerg.r...@kuehne-nagel.com> wrote: > 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. >
