A few years ago, all the languages I would use started to have automatic unused variable warnings built-in. And yeah, by now when I hear of people that don’t have that, it’s very much a feeling of “Man, you live like this?”.
Scary indeed.
This one could be helped by always using this pattern whenever you write a function that returns a value, in any language, along with no early returns:
int func(...) { int result = -1; ... return result; }I always start with writing my result default value, ideally indicating failure, and the return line. Then I implement the rest. We often don’t have the luxury of choosing the language we work with that has the features we like, but consistently enforced code style can help with a lot of problems. Anyone can make mistakes like the one in this bug regardless of experience so every little bit helps.
I appreciate rust as much as the next dev. But you can define your own types in C just as well? And with the proper warnings and errors
-Wall -Werrorin place, any warning is an error, and implicit conversions should probably be a warning right?ETA: Just tried with the following C code and could not get it to fail with
gcc.typedef int t_0; typedef long t_1; t_0 test() { t_1 foo = 1; return foo; }Tried with
gcc -Wall -Wextra -Wpedantic -Werrorand it compiled just fine.No unit test?
The article said it pretty well:
if your answer to any perceived failing in a person is “just try harder”, you are either woefully inexperienced or a just a dick
That applies to writing impossibly comprehensive unit tests too.
Though really for a filesystem they should really do silicon-style verification (which we’re calling Deterministic System Testing now).
This is a pretty straightforward utility function that wouldn’t be that hard to test. It’s normal to have standards for code coverage as part of the review process, I don’t code in C but I’d be surprised if setting any of that up is actually that burdensome.
I disagree with your reference of that quote being applicable here though. In fact, adding unit tests is the exact opposite: that quote is saying ‘if your answer is “make less mistakes” …’ Unit tests in general are an acceptance of the fact that we will fail to be perfect and we need to mitigate that with extra checks. The article already said it had two human reviewers, so they’re not opposed to extra process to help ensure quality, unit tests are just another (actually very cheap) extra step.
