-
Notifications
You must be signed in to change notification settings - Fork 27
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
SuppressWarnings flexibility #120
Comments
I really like the idea of specifying |
I like the suggestion too - I really dislike modifying the source code to suppress warnings. I've thought about package-wide suppressions as well (there are a few cases in checkstyle itself where this would be useful - for instance suppressing certain checks only in the tests). The |
I prefer keeping |
I don't think anybody suggested otherwise? |
|
I vote against putting them into the same JSON :) |
Mainly the language of rules and exceptions to those rules makes more sense to me than suppressions but it doesn't matter. That's a good point @AlexHaxe, it might more sense like |
In fact, having both might not be a problem either. In this case I don't see increased flexibility or options as a downside or undue complexity (it can just a matter of combining rules from both, which is simple for json and haxe). i.e a cli option for the exceptions file separate, as well as the ones within the rules file ("default exceptions" if you want to word them that way) |
We could allow mulitple |
yea That could work too, if all |
Thoughts on the following format? @underscorediscovery @AlexHaxe @Gama11 {
"exclude": [
{
"packages": [
"test.checks",
"reports"
],
"classes": [
"utils.TestUtils"
],
"methods": [
"utils.BrowserUtils:getPixelRatio"
],
"checks": [
"all"
]
},
{
"classes": [
"utils.DeviceUtils"
],
"checks": [
"Dynamic",
"LineLength"
]
}
]
} |
Why so verbose when the same information can be expressed in one key:value per rule? |
Something like this then? {
"exclude": {
"test.checks" : "all",
"reports" : "all",
"utils.TestUtils": "all",
"utils.BrowserUtils:getPixelRatio": "all",
"utils.DeviceUtils": "Dynamic, LineLength"
}
} |
That is much cleaner to me, and definitely better.
This allows more contexts to exist without so many json nodes per context, and makes it simpler to migrate/update/change the contexts as needed over time. |
How abt this? Grouping them by checks. I like the above format but afraid of scattered excludes if there are too many. {
"exclude": {
"all": ["test.checks", "reports", "utils.TestUtils", "utils.BrowserUtils:getPixelRatio"],
"Dynamic": ["utils.DeviceUtils"],
"LineLength": ["utils.DeviceUtils"]
}
}
|
I think both have trade offs, in the above you have duplicate classes, in the alternate you have duplicate rules. I prefer the way it reads with |
Grouping by package / type / field seems more natural to me. I'm not sure about referencing fields with There's the C++-like option of Btw, I think the value should be an array ( Is there also a use case for the inverse? Only activate certain checks on certain packages / types / fields. |
Yea I think a filtered include is also a good idea, since I actually have (on first run) over 6000 messages just in one package to deal with - I would love to work by check, and I would love to work by package, type, or even function. The other option for field is |
You can already work by check by starting out with I don't think Haxe really has a syntax for accessing instance fields through the class name? |
When you have over 6000 checkstyle messages, that can be a bit overwhelming. My guess is a large portion of those messages will go away, once you start configuring checkstyle to use your code style instead of the default. If you are on a Unix machine (your screenshot uses Using grep you can work through a huge number of issues in a quick way, because you are looking at only one problem at a time. And once you fixed the first occurrence, the rest should be faily similar (unless it is a CyclomaticComplexity, MethodLength, ParameterNumber or TODOComment issue, those might take a bit longer to fully fix, so leave them for the end). |
@underscorediscovery implemented You can look at the config used for this project here. |
For interest sake I converted it to the alternate that I and @Gama11 mentioned, and sorted them by type just so we can compare. {
"checks" : ["EmptyLines", "MultipleStringLiterals"],
"token" : ["MultipleStringLiterals"],
"checks.coding.MultipleVariableDeclarationsCheckTest" : ["MultipleVariableDeclarations"],
"checks.naming.MemberNameCheckTest" : ["TrailingWhitespace"],
"checks.size.LineLengthCheckTest" : ["LineLength"],
"checks.whitespace.IndentationCharacterCheckTest":["TabForAligning", "IndentationCharacter"],
"checks.whitespace.SpacingCheckTest" : ["TrailingWhitespace"],
"checks.whitespace.TabForAligningCheckTest" : ["TabForAligning"],
"checks.whitespace.TrailingWhitespaceCheckTest" : ["TrailingWhitespace"],
"checkstyle.Main" : "Dynamic",
"checkstyle.Checker" : "Dynamic",
"checkstyle.ChecksInfo" : "Dynamic",
"checkstyle.token.TokenTreeBuilder" : ["CyclomaticComplexity", "MethodLength"],
"checkstyle.reporter.ProgressReporter" : ["MagicNumber"],
"checkstyle.utils.ExprUtils":["CyclomaticComplexity"],
"checkstyle.utils.ComplexTypeUtils":["CyclomaticComplexity"],
"checkstyle.checks.Check":["CyclomaticComplexity"],
"checkstyle.checks.CyclomaticComplexityCheck" : ["CyclomaticComplexity", "LeftCurly", "RightCurly"],
"checkstyle.checks.block.LeftCurlyCheck":["CyclomaticComplexity"],
"checkstyle.checks.block.RightCurlyCheck":["CyclomaticComplexity"],
"checkstyle.checks.coding.MultipleVariableDeclarationsCheck" : ["MultipleVariableDeclarations"],
"checkstyle.checks.naming.MethodNameCheck":["CyclomaticComplexity"],
"checkstyle.checks.type.ReturnCheck":["CyclomaticComplexity"],
"checkstyle.checks.whitespace.OperatorWrapCheck":["CyclomaticComplexity"],
"checkstyle.checks.whitespace.WhitespaceAfterCheck" : ["CyclomaticComplexity", "MethodLength"],
"checkstyle.checks.whitespace.WhitespaceAroundCheck" : ["CyclomaticComplexity", "MethodLength"]
} |
It's possible to run checkstyle on a directory with multiple source files that have the same name / package. How should that be dealt with (if at all?). |
At present, it will ignore all the classes with the same name/package. That's a rare edge case and I think it's ok to ignore all instances. |
Not sure how rare. For any collection of projects (flixel-demos for example), this is going to be common: there are a lot of |
Ok makes sense for collection of projects. |
I've been trying this out on dev branch, and have some thoughts. Firstly, the Secondly, the multiple config file requirement is not ideal. I shouldn't have to litter my repo with multiple files for a single project level configuration. I was hoping the "exclude": { "all":[] } nodes would be a child of the existing checkstyle.json first, and a secondary file could be specified with a matching format so that it's easy to merge them inside the tool code and serve both use cases. For sure, though, two files just for one checkstyle configuration is not fitting. Thirdly, the packages are currently relative to the With: And |
Thanks for the feedback @underscorediscovery, will definitely revisit this soon. |
Another note: It's not possible to use wildcard paths for exclude yet right? The issue being something like |
The idea of Your case the valid when running on samples or collection of projects and I am not yet sure how to solive it :) |
First things first @underscorediscovery, just added flexibility to specify "exclude": {
} |
Packages are currently relative to the -s like you said. When running on a package the excludes should be relative. It's a bit weird because of dot(.) notation. With: When running on |
Tested the above scenario locally and it works. |
I've been looking at using this lib for a while, but there are some important things preventing me from using it in an automated or realistic project context.
The most important is the control over suppression is not sufficient, and has some concerns.
Two of them are just about what you can suppress and how:
The next issue is a bigger for me, which is that in order to suppress anything, modifying the actual code is required. This is an instant blocker, because decorating code with arbitrary third party/external meta information is not an option. Not just because this makes a mess, but this becomes impossible if you need to suppress things from third party or vendor code that exists within your codebase.
My ideas to solve this would be to provide more specific suppression control rules, like:
some.pack
some.pack.Class
some.pack.Class:method
This gives you enough control to configure the project. It's possible to add
:method:lines
or similar but I think since code changes, line specific suppression seems impractical.And secondly, make an
exceptions
node or similar inside therules.json
which can contain a predefined list of the above suppression markers, i.eThis allows a user to keep all their exceptions to the project rules localized, rather than spread out across the source code, doesn't require modifying the code, and to me, encourages more specific and conscious additions to the exceptions with a cleaner lineage as to where and why they're added.
Note this shouldn't remove the meta option, just complement it and give alternative options and flexibility. I would however align the meta tag closer with Haxe style than the Java style personally :)
Any thoughts?
The text was updated successfully, but these errors were encountered: