-
Notifications
You must be signed in to change notification settings - Fork 608
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
proposal: enable staticcheck #1897
Comments
I can go ahead and enable it but I just wanted to ask first if there is a reason for disabling it in the first place? Is everyone okay with me enabling this linter? |
IIRC, staticcheck is super slow and warns for deprecations would prefer not having a linter that takes many seconds. Linting should feel almost instant. |
You're right. It's slow. Took 5 seconds on the first pass. Reused cache a second time, taking approximately 1 second. To mitigate, what do you think about the following:
I just shot myself in the foot in #1857 by leaving a lot of unused code. Since we tend to be working on many PRs concurrently while waiting on feedback, it's easy to miss things like this when context switching.
|
Why not just add the deadcode linter? Just does this one thing and is pretty fast |
I've been framing this in terms of the dead code detection benefit so far because of recency bias. However, With only a quick skim, these are the linters that I've seen to be manually pointed out in our reviews that can be covered by
Since our goal is to minimize manual linting in the code reviews and offset this work to linter, It would also help standardize the coding standards/styles across the repository. Currently, the styles are inconsistent, reducing the overall readability. We can always remove linters that we don't like as we go along. From my experience, |
rip, I'm torn. I remember ~4 years ago with SDK development, static check frequently making my computer unusable at lint on save, hence not wanting it. I also remember it being far slower than 5 seconds (it was in the 30 second to minutes regime, and would halt youtube in the background lol), so its possible theres been massive speedups / resource usage improvements since. I find it even more annoying to have multiple lint commands though, I want my editor to handle most linting annoyances for me. I would vastly prefer just one linting process that my editor does on save. Not sure 5 seconds is an ok overhead for that though. |
Just checked:
It had a 5x speedup in 2019: https://staticcheck.io/changes/2019.2/ (Look at those old cockroach db stats! SDK was similar), and another big one in 2020: https://staticcheck.io/changes/2020.2/ , so thats why the recollection of minutes / my system getting unusable is outdated. (and im on faster hardware now lol) Of the lints you were listing, I'm not totally sold on a lot of them being important or worth the slowdown. (The godoc one is an anti-feature imo! People consistently fought against it in golint and it got removed from many repos IIRC) I feel mediumly strongly that there should be:
Maybe its the case that static check on a small number of items is fast! Or that we can have offload some of these goals to other linters. I'm down for a second pre-release or pre-tag linting process thats slower as well cc @alexanderbez for further thoughts |
Looking into this more, the golangci-lint Which of the ones you listed is most of them, and has ~no execution time tradeoff. If we want stylecheck, thats also separated out into its own linter with golangci-lint. Similar for QF as "QuickFix". (I'm unconvinced of these atm, but should look at the diff to see!) Perhaps we should go with the approach of enabling the components of staticcheck we want via golangci-lint? |
Good catch, seems that there are 4 components:
From what I understand, there is a I will try to start enabling these ones by one in upcoming PRs so we can see what makes sense |
The candidate to be removed if
|
I think we added all sub-components! If make lint times are getting annoying, we'll come back and start turning some off |
Background
I noticed that our linters do not catch unused variables. Upon running
staticcheck
with:I discovered around 30 lint issues related to unused code. We should consider enabling
staticcheck
as this is a useful static analysis tool.Suggested Design
We can enable it via
golanglint-ci
without much effort:osmosis/.golangci.yml
Line 71 in a785de1
Acceptance Criteria
staticcheck
is enabledThe text was updated successfully, but these errors were encountered: