Remove gomnd from Golang CI #3330
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Most developers agree that magic numbers are problematic. However, the
gomnd linter lacks finesse to understand when magic numbers aren't magic
at all. Examining the context of where the number is used is often
enough to deem it non-magical.
Consider some common magic numbers flagged by gomnd: 0644, 8080. Without
any additional context, it's fairly likely these are a file mode and a
port number, respectively. It's even more obvious when presented with
the context:
```go
f, err := os.OpenFile("notes.txt", os.O_RDWR|os.O_CREATE, 0644)
```
The linter would flag this, even though it's completely obvious what
0644 is. The remediations for the linter's flag creates categorically
worse code. The most common learned behavior for developers facing this
linter is to simply constantize everything it flags:
```go
flags := 0644
f, err := os.OpenFile("notes.txt", os.O_RDWR|os.O_CREATE, flags)
```
This makes the code *harder* to read, since you now have to trace the
reference back (it's probably defined in some const block another file
away).
Option number two for remediating this is to drop a comment providing
literally zero information to the reader that they don't already have or
could get from the documentation of the function where it's used.
```go
//nolint:gomnd // 0644 is a file mode
f, err := os.OpenFile("notes.txt", os.O_RDWR|os.O_CREATE, 0644)
```
This is not to say that magic numbers are not a problem--they definitely
are. However, this tool has very low signal-to-noise ratio and causes
people to take action that makes the codebase worse just to silence it.
Reviewers understand when a magic number is confusing and can just flag
it by hand more reliably.
4 tasks
rbtr
approved these changes
Jan 7, 2025
|
/azp run Azure Container Networking PR |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most developers agree that magic numbers are problematic. However, the gomnd linter lacks finesse to understand when magic numbers aren't magic at all. Examining the context of where the number is used is often enough to deem it non-magical.
Consider some common magic numbers flagged by gomnd: 0644, 8080. Without any additional context, it's fairly likely these are a file mode and a port number, respectively. It's even more obvious when presented with the context:
The linter would flag this, even though it's completely obvious what 0644 is. The remediations for the linter's flag creates categorically worse code. The most common learned behavior for developers facing this linter is to simply constantize everything it flags:
This makes the code harder to read, since you now have to trace the reference back (it's probably defined in some const block another file away).
Option number two for remediating this is to drop a comment providing literally zero information to the reader that they don't already have or could get from the documentation of the function where it's used.
This is not to say that magic numbers are not a problem--they definitely are. However, this tool has very low signal-to-noise ratio and causes people to take action that makes the codebase worse just to silence it. Reviewers understand when a magic number is confusing and can just flag it by hand more reliably.