I've been slightly using Sonar for some years here. It has proved useful as a way to find some simple improvements (StringBuilder instead of adding Strings, etc) but on the whole any of the 'issues' less than "blocker" level aren't terribly useful. [1] And these days IDEs have a lot of this analysis built-in.
It was useful to me for a while as a stick to beat the developers into increasing their javadoc coverage and for its unit test coverage reports. Ari [1] "equals(Object obj)" and "hashCode()" should be overridden in pairs is a good example of where it can catch subtle problems. On 31/01/2014 5:22am, Michael Gentry wrote: > I agree with the self-documenting. We are evaluating SonarQube here and > need to tweak some of the rules, but it can give you some useful info. > > > On Thu, Jan 30, 2014 at 1:10 PM, Andrus Adamchik > <[email protected]>wrote: > >> My comment was tongue-in-cheek of course. >> >> Even though I don't agree with all of these assertions. Like "Remove the >> declaration of thrown exception 'org.apache.cayenne.di.DIRuntimeException' >> which is a runtime exception.". Such declaration may be redundant, but it >> makes things self-documenting. >> >> Andrus >> >> On Jan 30, 2014, at 8:46 PM, Mike Kienenberger <[email protected]> wrote: >> >>> On Thu, Jan 30, 2014 at 12:32 PM, Andrus Adamchik >>> <[email protected]> wrote: >>>> According to this we are completely awesome :) Everything is an "A". >>> >>> Not quite. I clicked on a few things, not sure what they would do, >>> and came here: >>> >>> http://nemo.sonarqube.org/drilldown/measures/330106?metric=sqale_rating >>> >> >> > -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
