[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Sonar analysis "false positives"
|
About item #2, we have this in our Sonar build job:
-Dsonar.exclusions="**/tests/**,**/test/**,**/stubs/**,**/Messages*"
I assume some Message classes fall through this exclusion because they have different names. Should we just remote the exclusion entirely?
Marc-Andre
________________________________________
From: tracecompass-dev-bounces@xxxxxxxxxxx [tracecompass-dev-bounces@xxxxxxxxxxx] on behalf of Matthew Khouzam [matthew.khouzam@xxxxxxxxxxxx]
Sent: Wednesday, 01 April 2015 1:22 PM
To: tracecompass developer discussions
Subject: [tracecompass-dev] Sonar analysis "false positives"
Hi,
After discussing internally, unless there are any objections some sonar
warnings will be marked as false positive since we are following the
eclipse rules and not our own. These are good rules but don't reflect
our code reality.
1- Annotation order on nullable annotations
We write
private final @NonNull String foo
sonar wants
@NonNull
private final String foo
2- In Messages only: we have public static not final fields without
getters and setters. It is how eclipse externalizes Strings, we are not
about to rewrite eclipse to appease a warning, even though it's valid.
3- In Messages only: our code style for messages.java fieldnames is as
follows: ModuleName_CamelCaseMessage, it's weird, but that underscore is
actually useful, so we will keep it.
Of course, feedback is very welcome!
BR
Matthew
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
