-
Notifications
You must be signed in to change notification settings - Fork 246
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
Consider allowing more linters #1579
Comments
I’m sorry, that attribution is incorrect; those linters have been disabled for years, and I don’t now care to track what was the default at which time. My primary point is that we are now very much diverging from the current default, which seems unintuitive — linter developers probably don’t care about utility / comprehensive coverage of our chosen set of linters, and per the examples above, quite likely to be suboptimal for this project. |
What are the list of linters, you believe we should enable? |
I have no expertise in that at all; that’s partly why this is an issue and not a PR. At this point my recommendation would be to either just switch to the default set (if we don’t have any opinion at all), or to at least enable the default set (because it’s likely enough to be useful, and if we want to be more strict, sure, why not). |
I agree, I think we need to start turning on more of the linters and starting with the default set would be great. Getting to the point that podman, buildah, common, image and storage supported the same set should be the goal. |
This was changed in #1615 , but the configuration still disables 4/7 default linters. |
After @Honny1’s work I think we can now enable |
I will create PR. |
@mtrmac Here's a list of linters that I think would be nice to have:
These linters are stricter, but they would be beneficial:
Which ones would be a good idea, created an issue for allowing? Cc: @rhatdan |
I am fine with adding these linters. |
Thanks! As far as I care, just using all of the default is good enough to close the issue, but this is also a good place to concentrate discussion about non-default ones. Most importantly, I’m not a c/storage maintainer and this is not my decision. Dedicated maintainers should choose what works best for the project.
This one is attractive to me in the sense that VS Code seems to include it by default, so having it enforced would decrease noise.
I’m ambivalent: It does find useful opportunities for simplification, OTOH sometimes having a meaningful abstraction is better than satisfying this, especially in tests (“
It does find some bad test code at least, but otherwise the false-positive rate seems pretty abysmal. I’m tempted to be flippant and to say that if this were “solved” by uncommented unscoped
Hum. It does find large chunks of similar code, but it’s not always obvious how to structure it in a less redundant way (e.g. the This code base does have a bit of a tendency to have functions which should be separate files… OTOH I’ve seen PR contributions proposing to enable this then try to satisfy such linters by chopping functions in half in completely nonsensical places; and people “trying to get things done” just slap a |
We can configure linter to ignore some specific rules that we found false positives.
I agree with you. I think excluding tests from linting would be a good idea.
We can set the threshold to
I agree with you, but I would say this can force the reviewer of PR, but it will add time to merging PR. |
I have tried to configure linters.
Results:
I think some of them are interesting. WDYT: @giuseppe @mtrmac @nalind @saschagrunert |
The |
@mtrmac You're right about
Okay, I'll create issues for them and then we can close this issue. |
@mtrmac |
#1522has disabled 5 out of the 7 default golangci-lint linters. That seems excessive.For the record, currently:
At least the “error return”, “return copies lock value”, “the cancel function returned by context.WithTimeout should be called” parts seem relevant and valuable.
The text was updated successfully, but these errors were encountered: