Pedantic Coders: Warnings are Waste!

Some days ago I had a discussion with a Scrum Master, a Project Manager, and the team leader of a bunch of developers. We talked about an upcoming big project and how to guarantee high quality output right from the start.


At one point in the discussion I thumped the table and raised my voice:
"No, I do not want to see a single warning! If there is a single tiny warning I will declare the result invalid and failed!"


Everybody looked at me wondering about such a hard call. Let me explain why my request is so important:

Any Warning is Pure Waste!

Imagine the typical logging mechanism in your software. As your system grows your logging output grows in parallel. If there are several developers working on that system anyone of them at some point needs some private debug logging. Or maybe some informal output is written to the log files of the running software.


Now imagine the guys working as administrator, service technician, or customer service manager. What do they expect of this software in their specific role? If the customer did not report an issue, they expect an empty log file, nothing else! Every single line of informal or warning message would be pure waste for them.


The system has to write output only if there really was a problem the user could experience. This is a general constraint of software architecture and design your developers have to take care of.


Now we come to the deeper and underlying reason of my request: your compiler must not show a single warning!


"Yes, in theory, but we have old legacy code. And there are always language specific things that just throw a warning."


Don't allow yourself and your team to be that lazy! No, there is not any reason to let your compiler talk to you. Your compiler has to be silent. If it really wants to raise its voice, the message has to be of major importance! Any other gibberish compiler output is pure waste and distracts from important things.


"If you really want this, we could suppress all warnings in the compiler settings."


No, stop, you didn't get it yet! My request is not about hiding important messages, it is about avoiding important messages. Any compiler warning your code produces is an important hint to a possible defect in your code. In my point of view a compiler warning has an even higher priority than a red unit test.


Go and fix your code! Make it beautiful and clean. And let your team define a working agreement or even include in the definition of done as follows: "Code producing any compiler output is not done!"


I don't know why lot of developers do not have the attitude to be a pedantic coder. Maybe modern developers have lost that discipline because they got too used to deal with uncompiled scripting languages. Maybe they simply lack the knowledge of handling any theoretically possible error situation in their code. Back in the old days when I took a system programming course at university, we had to prove our skills by executing this command:


   gcc -ansi -pedantic mysource.c


You should do the same nowadays by applying following rules:

• Never suppress compiler messages
• Analyze every compiler output and take a deep look at your code to avoid that output
• Handle any theoretically possible error situation in your code, or to be more precise:
• Handle any theoretically possible error situation in your code even if you think it will never happen

Be a pedantic coder and do not allow warnings!

Be lean and remove waste!

Inspect and adapt!