I feel that linting has a lot of potential and is currently underappreciated. You can create rules that are heavily semantic in a way that would be impossible or extremely hard using a type system. Add to that that you can give useful error messages that include links! A type system might allow you to express an invariant, but when it's broken, it can be very hard to understand and communicate what the problem (let alone the solution!) is.
Finally, like the article touches on, linter errors can easily be ignored which means that you only have to get them, say, 80% right to add value. If an error appears somewhere you don't intend, you just ignore it with a comment.
Goland devs have been doing that since the inception of the language since the standard library ships with a Go parser. It's a no brainer for modern languages.
Code reviews shouldn't be spent catching formatting errors or naming conventions and coding guideline enforcement should be fully automated on a continuous integration server.
> You often find programmers recommending to configure C compilers with -Wall, which turns all warnings (which typically "inform") into errors ("block").
"-Wall" turns all warnings on . What turns them into errors is "-Werror".
In a project you distribute to other people it's a horrible idea because different compiler versions will give different, sometimes wrong or spurious, warnings, and so it'll randomly fail to compile even tho the code is completely correct.
: Well, not "all" warnings, just the ones in the "all" set. It's a bit misleading.
But I agree that the name is misleading. Worse is that nowadays it's the "standard name", and it's widely known to mean "most", so changing it would be confusing.
I also agree with the linting approach, and do the same myself:
- Automatically enable as many high-confidence checks as we can (if we want low-confidence 'suggestions', they can be run manually)
- Make them block (eventually, e.g. via a commit hook or a failing test)
- Allow '# disable-foo' annotations (with accompanying comment) when needed (with code review judging whether it's an appropriate solution or not, just like anything else)
Commit hook is too early, at least on a development branch. I want to be able to preserve things with commentary without making sure they work at all, much less making sure they're lint free.
Maybe there could be like a grace period instead. Like, if you do not fix this within 30 days, new builds will be blocked.
In Rust, #![deny(warnings)] is consider bad practice for the reasons explained in this article - it blocks progress too early.
Rather setting RUSTFLAGS="-D warnings" in CI will easily prevent warnings from being committed.
Incremental compilation helps, but fast performance in the non-incremental case also matters, or you might get something like Julia's "time to first plot" problem.