What if there were a way to get feedback on your code every time you compiled?
As developers, we depend on feedback to tell us how good our code is. That’s why I’m passionate about unit tests and TDD: they give me feedback quickly, and the feedback is so good that I’ve come to depend on it. Unit tests are faster than manual testing, and faster than acceptance testing. But there are forms of feedback that are faster still…
I’ve seen crashers ship which could have been prevented altogether, simply by enabling more compiler warnings. The sooner you detect a problem, the cheaper it is to find and fix. So let’s all dial up our Xcode warnings to catch more problems at compile time. …But how high should the warning settings be?
[This post is part of the series TDD Sample App: The Complete Collection …So Far]
Before you increase your Xcode warnings, drive any existing warnings down to zero. Fix the problems where you can. Where it’s too much, disable that particular warning for now.
You don’t want noise that hides useful information. If you put up with a list of “the usual warnings,” you won’t notice when a particularly serious one creeps into the list. This also applies if you use
#pragma warning, or have a script that flags TODO as a warning — you’re just adding noise. Get to zero.
Once you have a clean slate, start enabling more Xcode warnings. Do this at the project level so that it applies across all your targets. Gradually turn it “up to eleven,” rebuilding after each setting change.
Some warnings will be excessive for your codebase. Others simply don’t work well with Apple’s frameworks. Don’t worry about those, just keep going down the list. Check out Peter Hosey’s excellent description of the warnings he uses.
When you reach the bottom of the “Warnings” sections, skip over a few sections and do the “Static Analyzer” sections as well.
Click-click-clicking through a new project to turn on all these Xcode warnings is a pain. I made an xcconfig to make life easier, called XcodeWarnings.
To add XcodeWarnings.xcconfig to your project, drag it in. Where it prompts “Add to targets,” deselect all targets. (Otherwise, it will be included in the bundle.)
If you don’t have a previous xcconfig, click on your project Xcode’s Navigator pane. In the main editing area, select your project, and select the Info tab. For each of your configurations, select XcodeWarnings at the project level:
(If you do have a previous xcconfig, then edit it to
Whether you add XcodeWarnings as the root xcconfig or #include it from another one, it’s time to clear out any overrides to let the xcconfig take control. Still at the project level, select the Build Settings tab. Find your way down to the first section of Xcode warnings, labeled Apple LLVM x.0 – Warning Policies. Click the first entry:
Then scroll down through the various Xcode warning sections. When you reach the last one, shift-click the last entry. This should select all the warning settings. Press delete. This will clear the project-level overrides, causing the settings to fall back to what the xcconfig specifies.
Do the same for the static analyzer settings. Keep scrolling down and find the section labeled Static Analyzer – Analysis Policy. Again, click the first setting, then scroll to the last static analyzer section. Shift-click the last entry, and press delete.
…That may sound complicated, but it takes longer to describe than to do!
Once you clear the overrides, XcodeWarnings.xcconfig will be in full effect. If you’re starting a new project, you’re all set. But if you’ve added this to an existing project and rebuilt, you may have a large pile of warnings. Start by commenting out specific lines in XcodeWarnings.xcconfig (use ⌘-/) until you are back to zero.
Then one at a time: Take a line you commented out and hit ⌘-/ to bring that setting back into play. Rebuild, and decide what to do. Either:
There is another approach to turning warning settings “up to eleven”, and that’s to specify
-Weverything in “Other Warning Flags”. This turns on all the visible Xcode warnings, along with other Clang compiler warnings that Apple has not made visible in the Xcode project settings.
-Weverything is so strong, people usually add other flags to turn off some of those extra Clang warnings.
If that works for you, great. Personally,
-Weverything is too much for me. I get frustrated with the invisible nature of those hidden warning settings. So I prefer XcodeWarnings.xcconfig where everything is explicitly listed.
Remember, this is all about getting feedback on your code to catch problems early. As long as you turn your settings up to eleven, it probably doesn’t matter how you do it — as long as you do it. Try XcodeWarnings and see if it helps you. Turn up the warnings, drive them to zero, then stay at zero!
Question: Which Xcode warnings do you enable? Which do you disable? Do you use any of those hidden Clang warnings? You can leave a comment by clicking here.
Did you find this useful? Subscribe today to get regular posts on clean iOS code.[This post is part of the series TDD Sample App: The Complete Collection …So Far]
Jon is a consultant on Clean Code for iOS, focusing on Test Driven Development, unit testing, refactoring, and design. He's been practicing TDD since 2001. You can learn more about his background, or see what services he can bring to your organization.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.