chore: Lint tests#5709
Conversation
|
Hmmm. I disagree with the linter in some places here. I think a field name like |
|
@mholt -- indeed, I disagreed with it too :). Please lmk if I made any changes based on its disagreeable choices. I basically finished this one out by disabling a few things:
I'f you'd like any of them on, please let me know that too :) Ah, this one still has a few traces of unused-parameter in it, I'll get those out too. |
mholt
left a comment
There was a problem hiding this comment.
What's the problem with turning unused parameters into parameters named _? I do that sometimes, maybe it's good to be consistent...
I guess we do lose the self-documenting code a bit though.
|
@mholt -- those _'s were kinda the result of a misconfiguration. I think that their clarity (eg: we don't do anything with this) is less-good than the self-documenting code. I did this on ibc-go a while ago and ended up having to seek out names a bunch. Overall, I wanted to let the maintainers here know, the idea behind this set of PR's was to make writing code easier by transferring as much of the formatting work to a machine as possible. In the long run I'd recommend progressively tightening the linters, because you can catch small/easy issues (that can be maddening) that way, and also ensure that the code is really rigorously formatted. The reason I came to do this now, was the tweet about the feature freeze -- that's pretty much a perfect time to do this kind of work, because when linting we don't want to change what the code does at all (except maybe adding some tests, the linters are pretty good at finding places where we could add additional tests). Ah, and about linting the tests -- so that's not default behavior for golangci-lint but it probably should be. Once you're linting all of the code including the tests, you can get good consistency on the whole codebase, really fast. You can think of the linter configuration, as the thing that handles all of the formatting of the code, and in the future, you can use it to make sometimes surprisingly granular changes even to small stuff. |
| if IsUnixNetwork(network) { | ||
| host = a | ||
| return | ||
| return network, host, port, nil |
There was a problem hiding this comment.
This seems like a mistake -- the returns are named.
There was a problem hiding this comment.
ahhh, so it isn't a mistake actually, it's designed to make the code clearer. If you'd like me to change it back the way it was, just let me know.
|
|
||
| // Provision sets up the header operations. | ||
| func (ops *HeaderOps) Provision(_ caddy.Context) error { | ||
| func (ops *HeaderOps) Provision(ctx caddy.Context) error { |
There was a problem hiding this comment.
This variable isn't used, so I'm not sure why it needs a name. Naming it falsely implies that we're using it, whereas _ makes it clear we're satisfying an interface IMO. I know we talked about it before but it still seems misleading to me. Especially for an argument where the type makes things obvious; if this was a string or int, with a very vague function name, maybe a different matter.
There was a problem hiding this comment.
OK, I can change that setting, and that'd get applied universally.
There was a problem hiding this comment.
Universally for context args, or for every arg?
Because I think it could make sense for some args.
If it can't be configured in that way, I don't think that linter is helpful for us.
| } | ||
|
|
||
| var false bool | ||
| var falseBool bool |
There was a problem hiding this comment.
it was shadowing the name "false"
| err = writer.writeBeginRequest(uint16(Responder), 0) | ||
| if err != nil { | ||
| return | ||
| return nil, err |
AnomalRoil
left a comment
There was a problem hiding this comment.
Here are a few comments.
I think I agree with @mholt that keeping the _ instead of using named but unused parameters is clearer.
But I also think that if you're replacing named return with explicit returns, you might as well drop the named returns most of the time.
(Despite @mholt clearly loving these named returns, I think it doesn't help with readability of long functions, so it's probably better to have explicit return values.)
| full = CustomVersion | ||
| simple = CustomVersion | ||
| return | ||
| return full, simple |
There was a problem hiding this comment.
This is permuting both strings, no?
| return full, simple | |
| return simple, full |
Not that it matters here, but better be consistent.
| full = "unknown" | ||
| simple = "unknown" | ||
| return | ||
| return full, simple |
There was a problem hiding this comment.
This is permuting both strings, no?
| return full, simple | |
| return simple, full |
Not that it matters here, but better be consistent.
| // Set the ETag as a trailer header. | ||
| // The alternative is to write the config to a buffer, and | ||
| // then hash that. | ||
|
|
There was a problem hiding this comment.
Why the extra line here?
The comment is related to the next line.
| linters-settings: | ||
| revive: | ||
| enable-all-rules: true | ||
| # Do NOT whine about the following, full explanation found in: |
There was a problem hiding this comment.
Not convinced anybody "whines".
| # Do NOT whine about the following, full explanation found in: | |
| # Had to disable these out of the 77 rules. Full explanation of all rules found in: |
There was a problem hiding this comment.
Oh I think they're actually referring to the linter complaining when we don't really care about these things or they aren't relevant in our project. :) Not a person. But yeah, maybe the proposed change here is better.
| - name: unhandled-error | ||
| disabled: true | ||
| # Arguments added below do not trigger the rule. | ||
| # arguments =["os\.(Create|WriteFile|Chmod)", "fmt\.Print", "myFunction", "net\..*", "bytes\.Buffer\.Write"] |
There was a problem hiding this comment.
| # arguments =["os\.(Create|WriteFile|Chmod)", "fmt\.Print", "myFunction", "net\..*", "bytes\.Buffer\.Write"] |
| } | ||
|
|
||
| func (e StaticError) ServeHTTP(w http.ResponseWriter, r *http.Request, _ Handler) error { | ||
| func (e StaticError) ServeHTTP(w http.ResponseWriter, r *http.Request, h Handler) error { |
There was a problem hiding this comment.
this feels like it hurts readability. I agree with what @mholt was saying in an above comment, better keep the _ for these function whose goal is to fulfill an interface.
| resp := w.Result() | ||
| resp.Body.Close() | ||
| respBody, _ := io.ReadAll(resp.Body) |
There was a problem hiding this comment.
| resp := w.Result() | |
| resp.Body.Close() | |
| respBody, _ := io.ReadAll(resp.Body) | |
| resp := w.Result() | |
| respBody, _ := io.ReadAll(resp.Body) | |
| resp.Body.Close() |
You want to read the Body before closing it ;)
|
|
||
| // canHazCertificate returns true if Tailscale reports it can get a certificate for the given ClientHello. | ||
| func (ts Tailscale) canHazCertificate(ctx context.Context, hello *tls.ClientHelloInfo) (bool, error) { | ||
| func (Tailscale) canHazCertificate(ctx context.Context, hello *tls.ClientHelloInfo) (bool, error) { |
There was a problem hiding this comment.
😆 Very tempted to git blame who came up with that naming, fitting of Tailscale being the cool kids tho!
There was a problem hiding this comment.
That might have been me, being commissioned by Tailscale (to dev the feature, not to name it that, lol). 😶
|
|
||
| // Provision sets up the module | ||
| func (fw *FileWriter) Provision(ctx caddy.Context) error { | ||
| func (fw *FileWriter) Provision(caddy.Context) error { |
There was a problem hiding this comment.
| func (fw *FileWriter) Provision(caddy.Context) error { | |
| func (fw *FileWriter) Provision(_ caddy.Context) error { |
| // logger socket still offline; instead of discarding the log, dump it to stderr | ||
| os.Stderr.Write(b) | ||
| return | ||
| return 0, err2 |
There was a problem hiding this comment.
This changes the logic, but maybe in a good way.
Might be worth considering returning errors.Join of both err and err2 or maybe a new error wrapping both, tho.
|
Thanks for the review comments @AnomalRoil, appreciated! This PR will need rebasing, it's fallen a bit behind. |
|
Yes, thank you from me too, @AnomalRoil !
If I read you right, I think I agree. Named returns can be very elegant sometimes and even help improve correctness / reduce error-proneness, but if most/all of the return statements end up using variable names, the names should be removed from the return signature. @faddat Any interest in finishing this up? Apologies if it's overwhelming. That's just what happens sometimes with big changes 😅 We appreciate it! |
|
Closing due to inactivity -- however, we'd be open to finishing this when you are @faddat (or anyone else who would like to pick this up)! Maybe it would be easier to break it down into smaller changes if possible. |
THis PR lints the tests in caddy, too.