+1 cool stuff ;)
On 2018/12/20 09:58:09, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <[email protected]> wrote: > Hi Andi, > > yes - brain is needed - but experience shows that there is some around here > ;-) > I'm definitely not arguing in favor of automatic issue creation and most of > the issues seem to apply to master as well (not just v2). > > False positives need to be dealt with either > - by defining a custom rule set (eg. tag 'serialization' makes not much sense > in server only code) or > - using //NOSONAR comment (with a description) in order to silence the tool > per issue > > Polishing away 'Blocker' and 'Bug' can do no harm. > I would like to see Isis on [1] since even as is, it would be in the top > regarding quality (Bug/LOC). > > -j > > > [1] https://builds.apache.org/analysis/ > > -----Ursprüngliche Nachricht----- > Von: Andi Huber [mailto:[email protected]] > Gesendet: Donnerstag, 20. Dezember 2018 09:38 > An: [email protected] > Betreff: Re: Sonar on v2 > > 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" > <[email protected]> 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. > > >
