Skip to main content

Treat Warnings as Errors

It can be really hard to identify and see new warnings when you already have a lot of them. That is why this practice involves treating all warnings as errors so that they can be dealt with as quickly as possible.

Those warnings can come from different tools you use:

  • Compiler Compilation Warnings

  • I.D.E IDE Warnings

  • Linters Linter Feedback

  • Static Code Analysis tools Sonar Warnings

  • Package manager (Security issues or Dependency freshness for instance) Libyear Warnings

Why?​

In a lot of projects, warnings are never resolved.

AWS java sdk sonar

By accumulating them, you can be sure that at one point it will create you problems like defects, weird side-effects and will make you struggling for evolving your code base.

The good news is that you can fight it simply by changing some habits and forcing you solve those warnings on the flow.

Problems​

  • How to ensure software quality as soon as possible?
  • How not to drown in warning messages from our tools?

How to​

Configure your projects / compiler​

You can simply configure your tools to treat every warnings as errors.

For example, in dotnet you can compile through:

dotnet build -warnaserror

or even better you can configure it in the csproj file:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

Here is another example in java with maven:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>${maven.compiler.version}</version>
    <configuration>
        <source>17</source>
        <target>17</target>
        <failOnWarning>true</failOnWarning>
        <showWarnings>true</showWarnings>
        <compilerArgs>
            <arg>-Xlint:unchecked</arg>
            <arg>-Xlint:rawtypes</arg>
        </compilerArgs>
    </configuration>
</plugin>

Configure Static Code Analysis​

In static code analysis tools like SonarCloud you can configure Quality Gates defining rules for making an analysis successful or not: Sonar Quality Gates

You should configure it to be the more drastic as possible and not authorizing any warning in it. If at one point the analysis fails apply the lean principle Stop the line and fix it.

You should really treat those warnings as defects on your production line.

Have 0 tolerance for warnings​

It is a team practice, everything can not be automated so you should really align inside your team on this principle of 0 tolerance for warnings.

Constraint​

  • Configure your tools like explained above on your current project
  • Fix every warnings in mob if necessary (you will learn a lot)

Resources​

X

Graph View