original post by @metalslugx

original thread by @pukicho and several other users

exchange between @lmaonade​ and Anonymous

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.

No. 114