-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make pragma syntax more intutive #188
Comments
Yes, I agree that this is a good idea. Current syntax is too counter-intuitive. |
Any update on this? I just write the pragma rules which like the example in the readme and find it not working. 😂 Debug and read the source code... i have to invert all the rule now. |
Without any code changes, the confusion comes because the examples look like they mean "turn on coverage if the rule matches" when it is the opposite. This would be clearer just having an example like:
Would be clearer with a code sample like:
|
In #179 and #187, there was confusion about the current pragma syntax, and that
pragma: some
actually meanspragma: no cover if some
.Whilst the situation can be improved by README changes (covered by #187), I wonder whether adjusting the supported syntax might help make the rules self-documenting, and reduce the chance for confusion?
For example, what about this syntax?
ie:
coverage-conditional-plugin
would strip the literal string prefixno cover
(if found), leaving the rule name ofpy-gte-311
, and then behave as it does currently.This syntax has the advantage of being clearer, and also has a nice parity with the existing
no cover
syntax.For backwards compatibility (and to support a more concise syntax for people who prefer it),
coverage-conditional-plugin
could still support the current syntax alongside the above new syntax.The text was updated successfully, but these errors were encountered: