October 2011 saw the passing of giants:
By his vested Interweb powers, Tim O’Reilly has declared that October 30 be Dennis Ritchie Day. In his honor, I wanted to write something that’s been bothering me about the way people are learning Objective-C:
As a programmer, your most fundamental tools are the programming languages you use. If you don’t know the tool, you simply won’t be able to express things with both simplicity and power. And while I’m glad for the sudden interest in Objective-C, I’m troubled that so many people treat it like some kind of bastardized Java. They jump straight into messaging syntax and Foundation classes, while bypassing the powerhouse that’s available to them.
That powerhouse is the C language.
Whenever test code has repeated patterns, there’s an opportunity to make it more expressive and readable. This can sometimes be done by creating a new OCHamcrest matcher.
“hasProperty” is something of a misnomer, because it’s not just for properties. Any method, without arguments, that returns an object, is fair game. But I couldn’t think of a better name; I think it communicates well. Let’s take a look at a before-and-after code example.
A little before-and-after may show you why I’m so excited about this matcher. Here’s a test I wrote before OCHamcrest 1.6:
As you can see, the test creates an array of two strings. It passes this array to the method under test, a convenience method that creates an array of MyDownloader objects. The expectation is that the resulting array will have URLString values matching the original array of strings.
What I don’t like about this test is that the verification has to go through a number of steps:
Quickly generate code for either Swift or Objective-C. Code snippets provided for both Xcode and AppCode.
With few exceptions, using the C preprocessor 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 use that you should double-check.
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 preprocessor idioms, 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.”
“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.
The book’s catalog of code smells relate to good practices of object-oriented programming. I’m going to start a series that is specific to Objective-C code smells. Here’s a tentative list to give you a preview:
I think this’ll be interesting, and sometimes even controversial. (Dot notation, anyone?) So be sure to come back — subscribe to keep up with the latest postings!
Question: What common Objective-C practices have you encountered that you might consider code smells? Leave a comment below.
Slogging through code is what we do for a living. What would you give to be able to improve your existing codebase?
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”?
Many years later, I find the term “refactoring” being thrown around in the workplace, at several software companies. Programmers and managers often talk about “refactoring,” when they usually just mean “rewriting.” I’ve seen nightmares brought about by so-called “refactoring” that introduced so many defects, it compromised the product ship date.
The Refactoring book, however, teaches a disciplined methodology of changing code in small steps, with automated verification of each step.
February 22, 2016 Update: Added Swift. Refreshed Objective-C too, for latest Xcode.
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?”
“Kata” is a Japanese martial arts term for choreographed patterns of movement. Also called “forms,” both students and masters practice these detailed patterns over and over, so that the movements can come without thought.
A “code kata” applies this idea to coding. Some use the term to refer to coding puzzles (how would you code this or that) but let’s be faithful to the martial arts metaphor. A code kata is a set of moves, meant to be memorized and practiced until they can flow effortlessly.
So a “TDD kata” is designed to train your TDD muscles. “Uncle Bob” Martin designed the Bowling Game Kata to impart the moves of Test Driven Development. I have taken his presentation and created a version showing these moves in Xcode, using either Objective-C or Swift.
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:
Longer answer: “eBay Instant Sale” went live in the App Store two days ago. I can’t share the source code with you, of course. But here’s the unit test coverage:
It was written almost entirely using TDD. Sometimes tests weren’t written first (especially the code by a new engineer I couldn’t mentor because I was away). But test first or test last, they got written.
“That’s fine,” you may say, “but what benefit did they have?” If you’ve never done TDD, you haven’t felt the empowerment it brings. Read the following statements twice:
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…