[
https://issues.apache.org/jira/browse/MCHECKSTYLE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185269#comment-16185269
]
Tibo commented on MCHECKSTYLE-341:
----------------------------------
I think maven is the right tool.... :)
It's more than discipline, sometimes you fix checkstyle issues without
noticing. You want to know about it ASAP, whatever can be enforce in the build
tool should be enforce because you want a fast feedback.
IMO SonarQube and such are nice tools to display metrics and enforce quality
gates that can't be easily done elsewhere but If I have something I want to
enforce, I should enforce it wherever I can and the closest to the developer,
the best.
In this case having a "expectedViolations" flag will give more relevant
feedback to our developers for free (no perf impact, no negative consequences)
I am pretty sure that mostly everyone who is using "maxAllowedViolation" right
now would rather have an "expectedViolation" flag instead...
> Introduce an expectedViolation flag
> -----------------------------------
>
> Key: MCHECKSTYLE-341
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-341
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
> Components: checkstyle:check
> Affects Versions: 2.17
> Reporter: Tibo
> Priority: Minor
>
> We are trying to fix our tech debt step by step using the maxAllowedViolation
> flag and reducing the number slowly.
> We have 400+ maven module in our project and developer never update this
> flag, So basically when someone is fixing checkstyle error without updating
> the flag, it leaves room for another developer to introduce new errors...
> I would like an expectedViolation flag just to force people who are fixing
> issues to also update the count... It could be called "expectedViolation".
> The difference with the maxAllowedViolation flag is that this one would also
> fail when the number of actual violation is less than the "expectedViolation"
> flag.
> I believe the maxAllowedViolation should have been an expectedViolation from
> the start. I don't believe anyone wants to leave room for violation, you just
> want, for an existing project, to explicitly specify the current number of
> violation and disallow through pull request the number to go up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
