With few exceptions, using Xcode preprocessor macros is a code smell. C++ programmers have had this beat into them: “Don’t use the preprocessor to do something the language itself provides.” Unfortunately, more than a few Objective-C programmers have yet to get that message.
This post is part of the Code Smells in Objective-C series.
Here’s a handy command to run from Terminal. It examines source files from the current directory down, showing preprocessor macros use that you should double-check.
find . \( \( -name "*.[chm]" -o -name "*.mm" \) -o -name "*.cpp" \) -print0 | xargs -0 egrep -n '^\w*\#' | egrep -v '(import|pragma|else|endif)'
This command builds in some exceptions. For example,
#import directives are vital.
#pragma mark can be useful. …But I want to question pretty much everything else! Why does it matter? Because every time you use the preprocessor, what you see isn’t what you compile. And for
#define macros used as constants, there are certain pitfalls to avoid — when we could just avoid them altogether.
Here are some common Xcode preprocessor macros, and how to replace them:
Code smells. I’ve mentioned “code smells” at work, only to discover that my coworkers didn’t know what I meant. It’s basically a diaper-changing metaphor: “If it stinks, change it.”
A code smell isn’t “awful code that makes you hold your nose.” Rather, it’s a simple indication that something may need to be changed. Quite often, you won’t notice a code smell until someone else describes it. This is what Kent Beck and Martin Fowler did in the Refactoring book: created a list of smells, and what to do about them.
What would you give to be able to improve your existing codebase with complete safety?
Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.
The Refactoring book completely changed the way I code.
In 2001 while searching for information on design patterns, I discovered the original wiki, and stumbled on Extreme Programming. This led me to a software development conference in 2002 called SD West. There I attended a session by Martin Fowler, and knew that I had to pick up his Refactoring book that day.
How could I resist a book that promised to teach me about “improving the design of existing code”?
How do you learn Test-Driven Development? I could explain the principles and practices of Xcode TDD, but the question that comes back is, “But what do I actually do in Xcode?”
Unit test code is often tricky to read. Test output is often hard to read. There’s got to be a better way.
Hamcrest is an important tool for writing unit tests. It’s now a standard feature of jUnit, and lets you build test expressions that are expressive and readable:
I’ve ported Hamcrest to two languages:
Since Quality Coding focuses on iOS development, I’ll write about OCHamcrest on this blog.
…But Justin Shacklette beat me to the punch! His post Intro to OCHamcrest is a nice overview. He introduces the many “matchers,” illustrating them with code samples. He even makes special notes to call out areas that might trip you up.
I’ll eventually write about OCHamcrest myself. Until then, go check out Justin’s writeup.
Any questions about OCHamcrest? Leave a comment below.
Update: Apple took this to heart, and improved the unit test template in Xcode 5 and greater.
Xcode 4 has a File Template Library for creating new files. It includes a unit test template called “Objective-C test case class.”
Don’t use it.
Wouldn’t you like your unit test development to go faster? Let me give you a better file template.
Apple’s template puts cruft in your project. Cruft slows you down.
What’s wrong with Apple’s unit test template? Depending on which version of Xcode 4 you’re using, the template can be unnecessarily complicated, due to a distinction between logic tests and application tests that no longer exists.
But the template’s description reveals an ongoing problem: “An Objective-C class containing an OCUnit test case with a header.” A header? What for?
Test-Driven Development: Does it work for iOS apps?
Short answer: Sure! Here’s an example:
Yeah, that’s a really old image, and no, you can’t find this on the App Store anymore. But this was an app published by eBay. Here’s the unit test coverage:
Xcode unit testing has come a long way for iOS development. How does it measure up? I wrote this post when Xcode 4 came out, but many of the pros & cons still apply. For unit testing, Xcode has come a long way, but there’s still a lot of room for improvement.
Before Xcode 4, I recommended adding third-party unit testing frameworks such as Google Toolbox for Mac (GTM) and GHUnit. But with Xcode 4, the out-of-the-box tools are mostly sufficient. I say “mostly,” because it’s still a mix of the good, the bad, and the ugly. But, mostly good! Read on for a rundown of the pros and cons…
Hello, and welcome to Quality Coding — a place to share tools, tips & techniques for building quality into iOS development.
I’m Jon Reid. By day, I work as a code monkey in Silicon Valley, developing iOS apps at eBay (and of course, everything on this blog is my opinion, not that of my employer, etc., etc.). By night, I watch Dr. Who with my wife and teenage kids, practice electric bass for my faith community… and code for fun, working on tools like OCHamcrest and OCMockito to help me with my work.
I intend to cover topics here ranging from Xcode settings to continuous integration. My expertise lies in Test-Driven Development, so expect to see that as a major theme of this blog.