Archives For Project Structure & Language

Swift, here I come!

It’s time to start another version of the MarvelBrowser project. As I did with the Objective-C version, I begin the Swift version with a spike solution. But the first time was to see if I could satisfy Marvel’s authentication requirements. Basically, I needed to get the incantation correct. This time, I know the steps to take, but I will repeat them in Swift.

I have two goals:

  1. Make it work
  2. Make it Swifty

Could you give me feedback on the Swiftiness of my code? Continue Reading…

You spoke. The world is shifting. It’s time for Quality Coding to go Swift!

Better late than never.

Swift logo Continue Reading…

“Uncle Bob” Martin creates strong impressions, with outlandish costumes and black-and-white statements. If you understand that this is his didactic style, you can appreciate him fully. But people seem to enjoy jumping on statements rather than trying to grasp the whole. (Ah, Internet culture.)

I’m referring to the sentence: “You don’t need static type checking if you have 100% unit test coverage.”

This is one of the closing statements from Uncle Bob’s recent blog post, Type Wars. Various people jumped all over this, with much LOL.

100% COVERAGE? HA-HA!

Who’s right? Is Uncle Bob right? Are his detractors right? Continue Reading…

February 9, 2016 Update: Added Swift. Xcode 7.3 fixes things for Objective-C.

The biggest benefit of Test Driven Development is fast feedback. And so one of the best ways to keep your TDD effective is to make sure you get that feedback as fast as you can.

But most iOS folks use their production app delegate when testing. This is a problem.

That’s because when you run your tests, it first fires up your app — which probably does a lot. A bunch of slow stuff. And that’s a bunch of slow stuff we don’t need or want for our tests.

How can we avoid this? Continue Reading…

So you’ve tried to increase iOS unit testing in your organization.

Maybe you tried to lead by example, hoping others on your team would follow suit. Or maybe you tried to increase your own testing.

Either way, your efforts fell flat. Your new emphasis on testing was barely noticed, and eventually forgotten. Leading by example is key to introducing a test-driven culture to your organization. But it’s no good if no one sees your example.

If only there were a way to bring your tests in from the shadows, placing them front & center.

There is. It’s no silver bullet, but it’ll help. And it’s easier than you may think. Continue Reading…

Dot notation is okay, after all.

There, I said it.

I’ve been a staunch opponent of dot notation. I saw it as obscuring messaging, and encouraging programmers to violate the Law of Demeter through chained dots. I went so far as to characterize dot notation as an Objective-C code smell.

So it may surprise you to learn that I’ve recently adopted dot notation in my code! Here’s how it happened…  Continue Reading…

There are subtle issues around #import order. You may not believe me — until you try reusing code in a new project.

missing #imports

Unfinished Bridge 1 by Jason Thomas, used under CC BY-NC-SA 2.0 / Text added to original

In #imports gone wild! we looked at the problems caused by having too many #import directives. But it’s also possible that you have too few, resulting in bad header files — especially if you don’t pay attention to #import order in your .m files.

Minimal and complete

When it comes to imports, header files should satisfy these two conditions:

  • They should be minimal
  • They should be complete

“Minimal” just means a header file should import no more than it needs.
“Complete” means the header file imports everything that needed to compile it. Consider Continue Reading…

In my screencast of UIViewController TDD, I used an example of incrementing a counter and couldn’t help but give a slight aside: “We’ll increment it… ++count, instead of count++, please.”

WHAT YOU SAY!!

<rant>
I blame Apple for propagating poor incrementing style. Programming with Objective-C starts with the statement, “[Objective-C is] a superset of the C programming language.” But every example they give of incrementing a value uses someInteger++, ignoring the fact that C has two different increment operators!

  • Post-increment: count++
  • Pre-increment: ++count

The Wikipedia article Increment and decrement operators gives clear examples of the difference.

What performance impact will it make? None. The extra code for post-increment semantics is probably optimized away by today’s compilers. Even if it’s not, it’ll still have almost no impact. So what does it matter?

It matters to the reader. It matters because it shows a lack of familiarity with the language’s operators, which doesn’t fill me with confidence in your code. It matters because Objective-C Is Still C (Not Java!)

Say what you mean, rather than relying on side-effects.
</rant>

Question: Do language subtleties really matter? Leave a comment below.

I sometimes talk to myself. Our classes often do. But there are a couple of places where doing so is risky in Objective-C: init and dealloc.

"The Self-Talk Solution"

This post is part of the Code Smells in Objective-C series.

Here’s something I see a fair bit in code for Objective-C init and dealloc. I’ll give a simple example. Can you tell what’s wrong?

- (id)initWithFoo:(id)foo
{
    self = [super init];
    if (self)
        self.something = foo;
    return self;
}

- (void)dealloc
{
    self.something = nil;
    [super dealloc];
}

Hint: It’s those self-dots. They have a tendency to lull people into thinking they’re simple assignments. But remember, dot notation conceals messaging.

Let’s avoid dot notation and try again: Continue Reading…

Dot notation for messaging isn’t just an Objective-C code smell. It’s evil, I tell you!

Update: I recently changed my mind! See my post In Which I Embrace Dot Notation…

Dot notation: 100% PURE EVIL

This post is part of the Code Smells in Objective-C series.

…OK, so that’s hyperbole. I do manage to coexist with dot notation in projects that have it. But I won’t write it myself. Here are 3 reasons I avoid dot notation in my code: Continue Reading…