Mac OS Sex

Erica Sadun has a post over on TUAW explaining the correct pronunciation of "Mac OS X" (it's "mac oh ess ten", not "mac oh ess ex"). Some folks in the comments are not finding themselves able to deal with this.

Yes, Apple is being inconsistent: "Xcode", for example, is pronounced "ex code". And when you see that big "X" there you just want to say "ex". I totally understand. But I also agree with one commenter that there are people who will pronounce it wrong just to annoy. It's like Republicans who refer to the "Democrat party". It's petty and sad, but the best thing is to ignore it.

Anyway, I wonder if Apple missed an opportunity here. If they'd gone with the "ex" pronunciation, the name of their OS would have ended with "sex". They'd have thousands, maybe millions of people saying "sex" every day when referring to their products. Wouldn't that have been perfect subliminal advertising?

On the other hand, there are very good reasons why I am not in marketing.

Bending typography preferences

I've noticed that my habits around spelling, punctuation, and use of whitespace are sometimes dictated by the tools I use rather than what I might otherwise prefer.

A prose example

An example in my prose is that I recently decided to use the British style for quotation marks next to a comma or period.

The American style always puts the comma or period inside the closing quotation mark:

You say "potato," I say "potahto." (American style)

The British style puts the comma or period on the outside when it isn't part of the thing being quoted:

You say "potato", I say "potahto". (British style)

I've been debating for a while whether to switch outright to British style, since I use it when I compose emails about programming, where punctuation characters appear in all sorts of odd places and it's important to be clear when a comma or period is not part of the code I'm quoting. For example, American style would look like this:

To add a level-2 header, type "<h2>," the header text, and "</h2>."

That looks way too much like you're being instructed to type a comma and period. Better is this:

To add a level-2 header, type "<h2>", the header text, and "</h2>".

The thing that convinced me to use British style everywhere, not just for code fragments, was my iPhone. In iOS, when you enter two spaces, it assumes you're ending a sentence and adds a period for you. So you type

That's all<space><space>

and iOS changes that to

That's all.

The problem arises when I end a sentence with a quote. I like to type two spaces between sentences, so I type

He said, "That's all."<space><space>

(note I have to type the "." myself) and iOS proceeds to add an unwanted period:

He said, "That's all.".

By using the British style I can type this:

He said, "That's all"<space><space>

and iOS will give me this:

He said, "That's all".

Maybe this could be fixed with a little added smarts in iOS where it could recognize the American style and not add another period. One of these days I'll file a Radar and see what happens. But for now, it's the perfect excuse for me to commit to British-style punctuation, and it's an example of my tools determining how I punctuate.

[Update: Rats, I just realized the last example above is incorrect, because the period is part of the thing being quoted. In both American and British styles, it should be

He said, "That's all."

So I guess I'll have to file that Radar.]

A coding example

In my personal Cocoa projects, I was thinking of adopting my employer's coding convention for instance variable names:

  • Weak references begin with a "w".
  • Outlets begin with an "o".
  • Everything else begins with an "m" (for "member"; never mind that this is a C++-ism).

Example:

@interface MyViewController : NSViewController
{
@private
    MyViewController * wOwningViewController;
    NSTextField *      oStatusTextField;
    NSMutableArray *   mSubViewControllers;
}
@property (readwrite, assign) IBOutlet NSTextField *statusTextField;
// ...
@end

It's handy to have these typographical reminders that you don't want to release wOwningViewController in your dealloc, and that you don't want to message oStatusTextField anywhere that might be called before the nib is loaded.

But then I got Kevin Callahan's Accessorizer, which is very handy for generating code that is tedious to type by hand, such as property declarations. You can select an ivar declaration and by hitting a couple of hotkeys you'll get the corresponding @property and @synthesize statements.

Accessorizer knows that an ivar name is often the same as a property name, except with a prefix added. For example, you can tell it that "_" is your prefix for ivars and when it sees

NSString *_name;

it will give you

@property (readwrite, copy) NSString * name;

and

@synthesize name = _name;

The problem is, you can only specify one prefix, and my employer's convention uses three different ones: "w", "o", and "m".

Now again, maybe this could be fixed with a little added smarts. There could be an option where Accessorizer assumes the first character, whatever it is, is the prefix. I've emailed Kevin about this, and for all I know this feature will appear someday. But for now I'm sticking with "_" as my prefix for all ivars, which I kind of like anyway.

Other coding examples

Accessorizer isn't the only software that has affected my coding conventions. I've adapted my commenting style (and I think one or two other things) to be compatible with what I get when I hit Reformat in Xcode. Some prominent blogger, I forget who, said he went along with Xcode's formatting — it wasn't worth the effort to prefer something different — and I realized he was right.

I've been on the fence about whether to use spaces or tabs to indent. Part of me leans toward spaces because I might want to copy code into blog entries, and I haven't found a good WordPress plugin for syntax-highlighting code that both handles Objective-C and handles 4-space tabs. Also, I might want to paste some of my code into an email, and most people's email readers will expand tabs to 8 spaces.

Speaking of syntax-highlighting plugins, if I can find the perfect one maybe I'll re-enable “smart quotes” in WordPress. I turned them off because I didn't want curly quotes accidentally showing up in source code that I paste here.

MoreArty

I've been struggling to do something with NSTask which should be simple. To investigate my problem, I wanted to start with a simple working example of NSTask doing its thing. So I downloaded Apple's example project, called Moriarity.

I've complained about Moriarity before.

  • It uses the ancient pbproj project file format, which no recent version of Xcode can open.
  • The code is messy, with inconsistent indentation.
  • It uses the delegate pattern but calls it a controller, and doesn't name the methods like proper delegate methods.
  • It has a page of boilerplate legalese at the beginning of each file, getting between me and the code.
  • It duplicates class descriptions in the .h and .m files, with the only difference being "This is the header for…" vs. "This is the implementation for…".
  • Text-view ivars are named "…TextField".
  • Ivars are declared as id instead of using explicit class names.
  • The init method for TaskWrapper takes one array argument, the first element of which is the command path, instead of taking separate arguments for the command path and the command arguments.
  • TaskWrapper.h and TaskWrapper.m use "Classic Mac" line endings, which screws up diffs in GitX. Unfortunately I only noticed this after I'd already done some commits. In the future when I grab anyone's code with the intention of putting it in Git, I should make sure all the files have Unix line endings.
  • And of course it misspells "Moriarty".

In short, it drives me nuts. This time, though, I did something about it. I created a new project called "MoreArty". I copied all the Moriarity source files and resources, did some cleanup, and posted the code on GitHub. The next time I want to look at a trivial NSTask example, it won't drive me quite so crazy.

I could easily spend a couple of hours cleaning up the comments, but I left them mostly intact, because I don't have time.

I did notice one odd tidbit I hadn't noticed before. In the nib file, the app delegate is named "WatsonController", which I found interesting for historical reasons.

Junked titles

[UPDATE: I heard back from Scotty at iDeveloper TV, and he agrees with my gripe; he just hasn't had a chance to get to it, which is understandable given all he does.]

I agree with almost all of John Gruber's piece on web sites that use terrible page titles. For example, I agree that two good formats are

Source: Headline

as in "Cocoa with Love: Version control for solo Mac developers", and

Headline — Source

as in "Lost in China – NYTimes.com" — although I'd be willing to allow other separating punctuation. Unlike Gruber, I like double colons for separating parts of the title, precisely because they don't occur in ordinary prose. (This site uses "»" for that very reason.) I think either "NYTimes.com :: Lost in China" or "Lost in China :: NYTimes.com" would be fine.

For certain sites, I think another acceptable format would be

Headline on Source

as in "CocoaHeads Atlanta May '09: Aaron Hillegass on the Text System on Vimeo". Apple uses yet another format that I think is fine.

Gruber gives several examples of bad titles, but one case he doesn't mention is when a site junks the concept of a page title altogether, and uses the same title for all pages. One example is iDeveloper.tv. As I've said, I like the site. But every page is titled "iDeveloper TV, Training and Tutorials for OS X and iOS Developers".

This is annoying because if I have several tabs displaying pages on the site, it's impossible to tell which tab contains which page without bringing the tab forward and looking at its contents, which defeats the point of displaying the title in the first place.

Also, I like to archive articles in EagleFiler using a hotkey: I press F5 and the article is archived in the background. When an entire site uses one page title, EagleFiler uses that title as the headline of the article, meaning I have to go into EagleFiler and manually paste in the real headline, which takes away much of the convenience of the hotkey.

I sent feedback to iDeveloper.tv. I hope they'll agree and change the site accordingly.

iDeveloper.tv is great, except…

[UPDATE, 2012-05-18: The free videos have been moved to Vimeo. I've changed the links accordingly.]

I just enjoyed a talk by Dave Dribin called "Clean Code", over on iDeveloper.tv. Although I had heard a lot of Dave's advice before, sometimes in the context of other programming environments, it was good to hear it again well articulated and targeted to a Cocoa and iOS audience. The talk would have been terrific as a CocoaHeads presentation.

Some things I wholeheartedly agreed with:

  • write for people first, computers second
  • delegates > notifications > KVO
  • Boy Scout rule
  • keep methods small (something I strive for, but could do much better with)

The iDeveloper.tv web site is pleasant to navigate and full of good content. I just started up a talk by Aaron Hillegass on "The Many Faces of Data Persistence", and I'm enjoying it so far. I can see myself buying a video one of these days.

That said, there is one thing about the site that bugs me. I'll explain in my next post…

[UPDATE: Three things: (1) I heard back from Scotty at iDeveloper TV, and he agrees with my gripe; he just hasn't had a chance to get to it. (2) Scotty also runs a podcast called iDeveloper Live that I've also been enjoying. (3) I finished watching Aaron's talk and it was great from beginning to end.]