neugierig.org: Tech Notes

submited by

Style Pass

2022-01-13 02:30:03

Programming language ecosystems often involve tools that process code and produce errors or warnings, such as compilers and linters. Different programmers have widely different opinions on how to treat these systems. This culminates in disagreements around questions like: Should I treat all warnings as errors? Why is X an error and not a warning? Can I ignore lint warnings?

In this post I aim to give you a framework for how to reason about these systematically, with lessons learned from my recent years of work on programming language tooling for thousands of engineers at Google.

To begin with, we need to reset your biases, and to do so let's make up new words just for the duration of this post. Let's say a compiler/linter/static analysis/etc executes checks which can identify problems in code.

(There's potentially a third case of checks — what to do with problems like syntax errors that make the program completely uninterpretable. But more on that in a second.)