Description
Your feature request related to a problem? Please describe.
It took me way too long to figure out why golangci-lint wasn't telling me about so many linting errors that I could see with my own eyes.
This flag, which defaults to on, silently suppresses many important linting checks, and overrides the whole rest of your linting configuration in a very non-intuitive way.
The errors this setting suppress are, in many cases, extremely important to code quality.
Warning against using unsafe? That's important.
Warning against creating files and directories with permissions that are too open? That's important.
Warning about missing comments? That helps keep our codebase quality up, and is even mentioned in Effective Go. The comment warnings are especially egregious, in my opinion. The flag says "the rare codebase has such comments". That's an opinion, and I can't tell if it's saying that it's rare for people to write comments in the officially way (i.e. match the first word to the thing you're documenting), or if it's saying it's rare for people to not do that. But either way, it's certainly not rare.
This doesn't feel like a list of actual edge cases and false positives (for the most part), this feels like a list of one person's opinions about what kinds of linting errors matter. But that's what the configuration file is for.
Please reconsider this flag. I have seen what happens when you don't have sufficient linting combined with inexperienced devs... and the fact that the most popular linting program in the Go community is suppressing so many linting errors that are not edge cases, is extremely distressing.
--exclude-use-default Use or not use default excludes:
# EXC0001 errcheck: Almost all programs ignore errors on these functions and in most cases it's ok
- Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*print(f|ln)?|os\.(Un)?Setenv). is not checked
# EXC0002 golint: Annoying issue about not having a comment. The rare codebase has such comments
- (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)
# EXC0003 golint: False positive when tests are defined in package 'test'
- func name will be used as test\.Test.* by other packages, and that stutters; consider calling this
# EXC0004 govet: Common false positives
- (possible misuse of unsafe.Pointer|should have signature)
# EXC0005 staticcheck: Developers tend to write in C-style with an explicit 'break' in a 'switch', so it's ok to ignore
- ineffective break statement. Did you mean to break out of the outer loop
# EXC0006 gosec: Too many false-positives on 'unsafe' usage
- Use of unsafe calls should be audited
# EXC0007 gosec: Too many false-positives for parametrized shell calls
- Subprocess launch(ed with variable|ing should be audited)
# EXC0008 gosec: Duplicated errcheck checks
- (G104|G307)
# EXC0009 gosec: Too many issues in popular repos
- (Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less)
# EXC0010 gosec: False positive is triggered by 'src, err := ioutil.ReadFile(filename)'
- Potential file inclusion via variable
# EXC0011 stylecheck: Annoying issue about not having a comment. The rare codebase has such comments
- (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)
# EXC0012 revive: Annoying issue about not having a comment. The rare codebase has such comments
- exported (.+) should have comment( \(or a comment on this block\))? or be unexported
# EXC0013 revive: Annoying issue about not having a comment. The rare codebase has such comments
- package comment should be of the form "(.+)...
# EXC0014 revive: Annoying issue about not having a comment. The rare codebase has such comments
- comment on exported (.+) should be of the form "(.+)..."
# EXC0015 revive: Annoying issue about not having a comment. The rare codebase has such comments
- should have a package comment, unless it's in another file for this package
(default true)
Describe the solution you'd like.
Default this to false in the next release and mark it as deprecated, and then remove it in the release afterward. People that still want these suppressions can configure them themselves.
Describe alternatives you've considered.
Maybe remove all the exclusions that aren't truly edge cases. Maybe excluding test.Test from the stuttering linters is fine, but suppressing unsafe usage? Comments? Remove those from that list. But really, I feel like this is not a flag that should default to true at all, and if it exists, should only be edge cases.
Additional context.
No response