3 ms·

Error variable shadowing is a big one that occurs in go codebases. Along with the re-use of for loop variables, it is the most common Go footgun. The go langua

Error variable shadowing is a big one that occurs in go codebases. Along with the re-use of for loop variables, it is the most common Go footgun. The go language guys could fix both of these easily - force the caller to check error or explicitly drop it (_) optionally if non-null. That would almost completely eliminate the problem. I really like Go - I can pick up pretty much any Go code, from any open source project or any fellow engineer and read it with ease. No context, secret macros, implicits, etc. The code basically is what it appears to be. This is an enormous benefit in most contexts.

kjksf 4y ago
There are lints for that, if that's really a big issue for you. I don't want that because I don't want to litter my code with `_ = fmt.Printf()` `Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place. I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error. I get how you can forget something you do once a month. I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.
- foobiekr 4y ago
  I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with. Most people, I admit, do not review their dependencies, but that in and of itself is a problem. Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.

kjksf 4y ago

There are lints for that, if that's really a big issue for you. I don't want that because I don't want to litter my code with `_ = fmt.Printf()` `Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place. I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error. I get how you can forget something you do once a month. I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.

foobiekr 4y ago
I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with. Most people, I admit, do not review their dependencies, but that in and of itself is a problem. Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.