In this short and sweet opinion post, I’ll rant like a crazy man on the dangers inherent in living with compiler or linter warnings (at least I’m honest).
Warning Lights
I’ve been programming for over 30 years now and let me put it to you this way – the number of times I’ve opened a new (to me) legacy project and built it without warnings could probably fit on a single hand.
Why is this?
I think it’s somewhat like my tire pressure light on my car. The car runs fine, the tires seem fine, but the light stays on despite taking it to get checked out and despite telling the car’s onboard computer to recalibrate its tire pressure expectations.
Over time, I tend to filter out this yellow light as part of “normal operations”.
We do the same thing with code. If it doesn’t stop a build from succeeding, we tend to ignore it – especially if warnings were already present.
Why do we care?
The danger of this, of course, is that having existing warnings you ignore allows new warnings to hide in plain sight.
My car is the perfect example – while it operates just fine, if it suddenly does develop air pressure issues, I’m not going to notice until my tire is noticeably flat.
Similarly, you could be busy troubleshooting a problem and your compiler or linter is trying to point something out to you, but it gets lost in the noise. This has personally happened to me at least ten times.
We get it. You don’t like warnings. So what?
So, what can we actually do about this?
Start by actually reading your warnings.
I know, it’s a novel concept, but you need to look at the different types of warnings that you have. You should look at the count of warnings per type and address the most numerous and most severe ones first.
Make it a practice to address or (shudder) telling the compiler / linter to ignore a small group of warnings every time you make a change, you can pay down your debt of warnings over time.
You’d be amazed at how many warnings you can address in even a 15 minute block of time. Sometimes, just searching and understanding a warning will teach you new things about programming and shore up vulnerabilities you didn’t even know you had.
Just say No to Warnings
Once you get to that coveted 0 warnings level, I recommend you jump off the deep end and take it a step further.
Treat compiler / linter warnings as build errors.
Okay, please stop throwing things at me. Let me explain.
If you get to 0 warnings, you can stop from ever going higher by causing builds to fail if they introduce new compiler or linter warnings.
If you do this, once a warning exists, it is instantly meaningful to the developer who introduced it and cannot be ignored.
Note that this doesn’t have to explicitly fail builds on developer machines – You could use a more strict process in your CI/CD build pipeline than you do during normal development.
Treating Warnings as Errors
The implementation details of this will vary by language, but let’s cover .NET and JavaScript / TypeScript since that’s what I tend to write about the most:
For .NET builds, in Visual Studio, you can go into an individual project’s settings on the build tab and change its handling of warnings for the active build profile:
With JavaScript and TypeScript, it’s going to depend on what you’re using for linting, but I’ll assume you’re using ESLint since it is extremely popular and I’ve gone into it in depth before.
ESLint allows you to configure rule handling at a granular level by modifying your lint configuration.
For example, if I wanted to treat the max-lines analysis rule as an error on violation instead of as a warning, I’d write something like the following:
"rules": {
"max-lines": ["error", {"max": 200, "skipBlankLines": true}]
}
You can take a similar approach every time you encounter a new warning and add an error level rule for it in your lint configuration.
Closing
So, warnings might not kill you, but they’re a valuable tool in maintaining quality software over time.
Whether or not you address past warnings or treat new warnings as errors is up to you.
My primary admonition is this: you need to be ware of each and every warning in your application because your code is trying to tell you something.
If we stop treating warnings as decorative pieces of flair, we can stop and listen to what our code is trying to tell us and do what we all want: deliver better software faster.
The post Warnings are not Pieces of Flair appeared first on Kill All Defects.
Top comments (6)
I've recently just started adding the Microsoft code quality analysers to all my projects and enabling treat warnings as errors. Infinitely more robust code and just teaches you to be much more aware of little potential bugs
I use NDepend for .NET analysis and you can trigger build failures on new analysis issues or new ones past a threshold.
I really like the look of NDepend! Just can't quite warrant the outlay for a license at the moment :)
GREAT ARTICLE! And yes, I'm yelling that lol.
"Sometimes, just searching and understanding a warning will teach you new things about programming and shore up vulnerabilities you didn’t even know you had"
This is how I learn most things. I'm a bit OCD and can not stand the thought of having any errors/warnings left and I search and learn everything I can about the whole area of the warning until I know it so well it's all I think about for a while and then I end up doing countless tests purposely throwing errors in various methods and learning how to solve each. It may not be the best method of learning for students or those on a time frame, but lucky for me I'm a long-time hobbyist and have no deadlines... Most things I learned in my early years I learned because I had to fix errors and learned more about an OS from fixing those errors. Then I started learning programming and learned even more. It's inadvertent and inevitable at the same time.
This is good stuff. I do my best to get rid of warnings but sometimes it gets chalked up to youthful exuberance. glad to see an experienced developer validate my compulsions
I totally agree. Nothing is better then to finish a project with 0 on all errors, warnings and messages, and all the tests are green.