Keeping the code clean of warnings helps your productivity

In some Fortune 500 companies I worked we had an official policy of 0 compilation warnings allowed in the code. That was a good practice that saved us of many troubles. Since then I try to follow that practice in my projects.

Let's see an example:

        NSLog(@"Hello, World!");

        

        int i = 1;

        switch (i) {

            case1:

                NSLog(@"OK");

                break;

        }

If I placed this code in a project with the default settings created by Xcode, the result wouldn't output the "OK" string, due to the "case1:" typo which transformed the "case 1:" case statement into an unused label. The compilation wouldn't produce any warning. Neither would the static analyzer.

You can however catch such problems at compile time, by changing the default settings like so:

This enables all warnings. The following setting treats all warning as errors:

If I now try to compile I get this error:

Catching this bug at compile time is much better than later when the app may have been released.

Another useful setting to have is this:

which runs the static analyzer on every compilation. I found this combination of settings very useful to smoke out bugs shortly after they have been introduced.