When I looked at the data what I was most concerned were the critical level violations. I fixed some hours ago a bunch of them ( http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=e7cb002985859e26550d043db1e540d32b3a27fa) mostly being "Don't catch Throwables" (because it contains OutOfMemory, PermGenSpace etc. errors), which I consider real issues and they were the original cause for the email. The configuration ( top right ) will allow us to configure what is considered major, minor or ignored in a custom profile. But first Mickael Istria (which is the actual Sonar admin) or someone else will have to configure the LDAP access so that we can edit these settings (bug 391343<https://bugs.eclipse.org/bugs/show_bug.cgi?id=391343> ).
On Wed, Dec 12, 2012 at 3:34 PM, John Arthorne <[email protected]>wrote: > I glanced through these, but most of these rules are very subjective and > don't indicate technical debt in my opinion. For example the biggest source > of "violations" is using underscore in field names, or non-private fields > for example in our Messages classes. There might be some real problems > buried in this data but there is so much noise they are hard to find. Is > there somewhere we can configure these warnings? > > > > From: Sopot Çela <[email protected]> > To: E4 Project developer mailing list <[email protected]>, > Date: 12/12/2012 05:58 AM > Subject: [e4-dev] Keeping code analysis in mind > Sent by: [email protected] > ------------------------------ > > > > Hi e4 committers/contributors, > > I was looking at > *https://dev.eclipse.org/sonar/dashboard/index/10079*<https://dev.eclipse.org/sonar/dashboard/index/10079>and > wanted to propose that every now and then we keep in mind the technical > debt that we accumulate while making commits. I started by opening a bug > tracking the work that we do in this direction. Sonar allows you to drill > down to LOC level so it's pretty easy to find critical code patterns (like > catching Throwables etc). > > Whether you do it in your next commit (comply to good-code-rules) or > decide to do a clean up of previous code we would save ourselves trouble > for later. Now that we configured the code analysis infrastructure it is > time to use it. > > Sopot_______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
