NO [SONAR|PMD|CHECKSTYLE] authorized if commented : squid leys for PR

[Alix Lourme]

Hi,

To continue the thread on previous mailing list (NO [SONAR|PMD|CHECKSTYLE] authorized if commented), I would propose pull request for these 3 new rules.
(Unless you prefer a extension on 3 current ... like a boolean for justification acceptance).

Which squid keys I could use ?

Thanks in advance.
 Best regards.

[Alix Lourme]

Hi,

If these rules are really a non-sense for you, could I propose a more generic rule based on a regexp file/comment check (like checkstyle:Regexp).

With an extension of this rule, anybody could answer the original need.

Best regards.

[Nicolas Peru]

Hi Alix, 

As explained in Jira and in the previous thread such problems should be handled with the Sonarqube platform by marking the issue as won't fix. From my perspective, if introduce this kind of stuff the next step will be to parse the content of the comment because there will be some hack arounds to mute the issue etc and this is definitely a road I don't want to open. 

The main argument in favor of this for me is the fact that there is currently a not so nice handling of branches in the platform but then real solution lies in how branches are handled and not changing the behaviour of the rules. 

I am not sure I got clearly right the idea behind the regexp rule you propose Alix.

Cheers,

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/cb21f2cc-f208-4747-a131-26da39536a28%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alix Lourme]

Hi Nicolas,

Thanks for the reply. I understand the point of view, even if some operational cases could not be covered in this case. But it is a detail, thread closed.

I am not sure I got clearly right the idea behind the regexp rule you propose Alix.

It was a generic way to solve the debate.

With a new configurable "regexp rule" (regular expression & message), we can solve the problem, sample with checkstyle RegexpSingleline implementation  and CHECKSTYLE:OFF :

<module name="RegexpSingleline">
    <property name="severity" value="..."/>
    <property name="format" value="CHECKSTYLE:OFF(\s)*$"/>
    <property name="message" value="It is mandatory to comment on why the following code is excluded from Checkstyle checks."/>
</module>

But parameters are evil and checsktyle RegExp* will not be implemented in Squid (Rejected Checkstyle rules) :-).
=> I will implement this rule for our context, it seems to be specific at our historic usage.

Best regards.