Objective-C Is Still C (Not Java!)

Do you have your C book?

Do you have your K&R book?

October 2011 saw the passing of giants:

Simplicity. Power.

  • Steve Jobs. You work with his toys everyday.
  • Dennis Ritchie, inventor of the C programming language, co-inventor of Unix. You work with his stuff everyday (but we forget that).
  • John McCarthy, inventor of Lisp. We use the descendants of his invention every day (without realizing it).

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:

Objective-C is still 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.

Continue reading

How OCHamcrest’s “hasProperty” Can Make Your Tests Simpler

Shares

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

Property in Europe by Images Money, used under CC BY 2.0 / Added text to original

OCHamcrest features a great new matcher submitted by Justin Shacklette: hasProperty.

“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.

“hasProperty”: before

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:

- (void)testArrayFromURLStringArray
{
    // given
    NSArray *URLStrings = [NSArray arrayWithObjects:@"one", @"two", nil];

    // when
    NSMutableArray *downloads = [MyDownloader arrayFromURLStringArray:URLStrings];

    // then
    assertThat(downloads, hasCountOf(2));
    MyDownloader *download = [downloads objectAtIndex:0];
    assertThat([download URLString], is(@"one"));
    download = [downloads objectAtIndex:1];
    assertThat([download URLString], is(@"two"));
}

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:

Continue reading

Generate Test Scaffolding & Stay Focused

Quickly generate code for either Swift or Objective-C. Code snippets provided for both Xcode and AppCode.

9 Code Smells of the Preprocessor (and Their Fixes)

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.

find . \( \( -name "*.[chm]" -o -name "*.mm" \) -o -name "*.cpp" \) -print0 | xargs -0 egrep -n '^\w*\#' | egrep -v '(import|pragma|else|endif|HC_SHORTHAND|MOCKITO_SHORTHAND)'

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:

  1. #include
  2. Macros
  3. Constants: Numeric constants
  4. Constants: Ascending integer constants
  5. Constants: String constants
  6. Conditional compilation: Commenting out code
  7. Conditional compilation: Switching between experiments
  8. Conditional compilation: Switching between staging and production URLs
  9. Conditional compilation: Supporting multiple projects or platforms

Continue reading

Code Smells in Objective-C

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.”

Code Smells

diaper” by beth darbyshire, used under CC BY-NC-ND 2.0 / added text

“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.

Code Smells Specific to Objective-C

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:

  1. 9 Code Smells of the Preprocessor (and Their Fixes)
  2. #imports Gone Wild! How to Tame File Dependencies
  3. 4 Ways Precompiled Headers Cripple Your Code
  4. Is Dot Notation in Objective-C 100% Pure Evil?
    …or maybe not! I switched, see In Which I Embrace Dot Notation…
  5. Objective-C init: Why It’s Helpful to Avoid Messages to self

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!

Other resources:

Question: What common Objective-C practices have you encountered that you might consider code smells? Leave a comment below.

Refactoring: The Book that Changed Everything for Me

Slogging through code is what we do for a living. What would you give to be able to improve your existing codebase?

Refactoring book

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”?

Refactoring: Co-opted in the workplace?

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.

Continue reading

Xcode TDD Kata: Practice with the Bowling Game

Shares

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?”

That’s what the Bowling Game TDD Kata is for. There’s an Objective-C version and a Swift version.

Xcode TDD Kata

Highkick by Pandiyan V, used under CC BY-NC 2.0 / Added text to original

What’s a code kata?

“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.

Continue reading

Hamcrest: A Tool for Readable, Powerful Unit Tests

Shares

Unit test code is often tricky to read. Test output is often hard to read. There’s got to be a better way.

There is!

OCHamcrest help

give me by sanja gjenero, used under Freeimages licence / Added text

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:

  • Readable source code
  • Readable diagnostic output

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.

See also: How OCHamcrest’s “hasProperty” Can Make Your Tests Simpler

Don’t Use the Xcode 4 Unit Test Template

Shares

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.

Apple's unit test template, and my replacement

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?

Continue reading

iOS Test Driven Development: Can It Really Work?

Share

Test Driven Development: Does it work for iOS apps?

Short answer: Sure! Here’s an example:

I developed this iOS app using Test Driven Development

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:

92% line 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:

Continue reading

Xcode Unit Testing: The Good, the Bad, the Ugly

Share

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.

Xcode unit testing is now fully integrated into the UI!

Unit testing is now fully integrated into the UI!

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…

Continue reading