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:ahu...@apache.org] Gesendet: Donnerstag, 20. Dezember 2018 09:38 An: dev@isis.apache.org 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" <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. >
