Quality Coding
Shares

Is Apple Stuffing Your Code with Pointless Cruft?

Shares

I have a confession to make. My code is clean. My email inboxes are nearly at zero. But my physical inbox, on my nightstand?

Oy vey. I don’t want to show you. Instead, here’s an image illustrating what my physical inbox feels like, when I stop to notice it:

It’s not like I mean to have a pile of clutter. But you know, it’s death by a thousand cuts. One item at a time, that corner of my life is becoming more cluttered.

As a protection mechanism, I’ve even stopped noticing the pile. But many of those items were put there by my wife, to make it clear that that item is my responsibility.

How about your source code?

Whenever you create a new project, or even create a new class, Apple puts things there. It’s our responsibility to decide what to do with them. Failure to decide leads to clutter. You may have even stopped noticing that the clutter is there.

So let me point it out to you.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Cruft: File comment blocks

Do your files start with something like this?

//
// TableViewController.m
// MyProject
//
// Created by My Name on 1/25/15.
// Copyright (c) 2015 My Company. All rights reserved.
//

Seven lines, plus a blank line. What’s it for? To tell me the name of the file I’m already looking at? To tell me the name of the project I already have open? It’s even more fun when files are renamed or moved to a new project, so the comments no longer match reality. (Pro tip: When you rename a file in AppCode, it offers to change not only any code references, but also comments and strings.)

Does it help me to know who first created the file? Besides, how much of the original is still there? Unless the file was copied across repositories, I can just check its history. Same with the date. I mean, thank goodness we stopped including revision history in file comment blocks. So why not take it all the way?

Cruft: Copyright statements

Oh, and that copyright statement… as far as I know, (c) isn’t even a valid copyright symbol. The word “Copyright” does fine. “All rights reserved” became obsolete in the year 2000.

But as far as copyright statements go, you have to do whatever your legal department says. When I worked at Adobe, source files had to have a wordy block of many lines, with a year range that needed to be updated — joy! When I worked at eBay, there was no such requirement. So whenever I created a new file, I stripped out the entire file comment block. The whole thing. When you opened one of my files, you were immediately looking at real lines of code, not scrolling to get to them.

For open source, I start with a short comment block for attribution, and a pointer to the license. That’s mainly because I expect the files to be shared to different places outside of my repository. In the MarvelBrowser project, I did this in commit 9bad6cc, “Add .txt file extension to LICENSE, and streamline file header comments.”

So my advice about file comment blocks is this: use as little as you can get away with. Preferably none.

Cruft: Educational template code

Create a new project. Or heck, just create a new class, subclassing something more specific than NSObject. You’ll see a ton of source code — more than I want to show. Here’s just part of what you get when you create a new Test Case Class:

- (void)setUp {
    [super setUp];
    // Put setup code here. This method is called before the invocation of each test method in the class.
}

Why is that there? It’s strictly educational. Apple is using code and comments to teach us — in this case, what test case setUp does, and that it should invoke super first.

So, learn what there is to learn. Then get rid of it.

(But leave one empty test, temporarily)

When I’m starting a new project, I do leave the Apple-supplied test case class in place — temporarily. I remove everything but add a single, do-nothing test method. Why? Because test targets have to have at least one test method to function correctly. If I’m rearranging the project before writing tests of my own, I want an empty test method sitting there. That way, I can verify that I haven’t messed up the test target settings. You can see this in the MarvelBrowser project in commit 8bfe6ca, “Delete template code.”

Cruft: Placeholder template code

Some templates come with empty class extensions, like

@interface TableViewController ()

@end

Get rid of it. If you need it later, you can re-create it. (Better still, let AppCode create it for you.)

I’ve also seen production code like this:

- (instancetype)init {
    self = [super init];
    if (self) {

    }

    return self;
}

It’s a placeholder, adding no value. Delete it until you need it. (Again, let AppCode create it for you by overriding init.)

Cruft: AppDelegate template code

Then there’s the AppDelegate. If you create a new project and select “Use Core Data,” your AppDelegate will be jammed full of Core Data setup code. It may help you get up & running quickly, but it doesn’t belong there. Again, it’s educational. But like Apple’s sample code, their template code puts everything together so you can read it. That makes sense for teaching “it should do this-and-such” in a condensed fashion. It doesn’t make sense for structuring clean code.

Case in point: anything that sets up a class as own data source or delegate probably violates the Single Responsibility Principle.

So, learn what there is to learn. Then get rid of it.

Does cruft really matter?

You may be wondering if Apple-generated cruft really matters. Here are some reasons I think it does:

  • Visual noise keeps me from quickly seeing what matters. File comment blocks are noise. Do-nothing methods that only invoke super are noise.
  • The best code is non-existent code. As I learned from Alex Stepanov, don’t treat code as an asset; treat it as a liability.
  • Don’t unquestioningly use Apple’s template code. What’s good for teaching isn’t structured for ongoing maintenance.
  • I want to TDD as much of my code as I can. This means creating a failing test case, then adding code to pass, then determining the appropriate design. That order is important.

Don’t read into this that I’m opposed to code templates — not at all! In fact, one of the reasons I feel free to delete setUp and tearDown from test code is that I have templates (for both Xcode and AppCode) to create them later. You can get these templates for your own use by subscribing to Quality Coding.

So I hope you’ll join me in getting rid of cruft. I just took a little time to apply the “Boy Scout Rule” to my physical inbox; I handled a single item in the pile, making it one step better. What if you did the same in your code?

What useless cruft can you find in your source files? Tell us about it by clicking here to leave a comment.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

About the Author Jon Reid

Jon is a coach and consultant on iOS Clean Code (Test Driven Development, unit testing, refactoring, 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.

follow me on:

Leave a Comment:

5 comments
Add Your Reply