NYTimes Objective–C Style Guide | Hacker News Reader

NYTimes Objective–C Style Guide

github.com

80 pointstater47 comments

I hate absurdly long variable names like this:

    static const NSTimeInterval NYTArticleViewControllerNavigationFadeAnimationDuration = 0.3;

I feel like if your naming convention forces you to have variable names over 50 letters long, there is a problem.

Objective-C's tendency to long names (variables, selectors, classes) makes it more "self-documenting" than any language I've worked with. Besides, it's not that bad with autocomplete.

Now if only that autocomplete would passively infer the current project prefix + (super)class name, so you wouldn't have to type it when it's "local"...

With Xcode it's just as bad as it looks. If you have multiple names with the same prefix you have to type it all or scroll in a list to select the correct item.

It even fails to complete types like NSString correctly when part of a method call. Not always of course, just when it gets confused, and then I have to delete and type again because the case is wrong.

Or press tab to get a partial completion and use the arrow keys to pick the right one?

I'm not an Objective-C native, but every time I write Objective-C it feels like I'm writing a short story.

    applicationDidLoad:withANotification:iWonderWhatTheWeatherTodayIs:LetsAskSiri:

>> I'm not an Objective-C native, but every time I write Objective-C it feels like I'm writing a short story.

That's the whole point of it ;-). Remember you usually only have to write the code once, but you or someone else may have to read it many times.

I used to hate long variable and function names in the past, and I used to hate named parameters. Going on the assumption the time spent typing the code was somehow relevant, and also feeling a little more badass being able to write all this cryptic gibberish to 'control the computer'. In time, I've learned none of this matters and readability of your code is one of the most important quality metrics of any piece of software that needs to be maintained by multiple people and/or over a long timespan.

It's also a sign that your language lacks namespaces.

Right, if only it used C#! Then it could use nice short names like ListViewVirtualItemsSelectionRangeChangedEventHandler or DataGridViewColumnDividerDoubleClickEventArgs.

haha, you win this round :) though using a Microsoft (or Java) codebase might be considered cheating.

Oh god. That's an artifact of the idiotic VB-style, non-generic event handling "pattern". If event handlers used normal functions like everything else this just wouldn't be a problem (those types just wouldn't exist).

It's a marketing ploy to get you to buy larger (wider) monitors in order to avoid line wrapping.

My only gripe about developing on a 13" MBP is not being able to have 2 buffers side by side without wrapping the snot out of half the lines.

++ for pep8 :)

> Asterisks indicating pointers belong with the variable, i.e. NSString text not NSString text or NSString * text, except in the case of global string constants.

I know I have it wrong, but I always feel that the the variable is of type "pointer to type" so isnt it fairer to have the asterisk paired with the type denoting it is of the kind "pointer to type"?

I've previously shared your opinion on this issue as well, but the first answer to this StackOverflow question shows one good reason why one should opt for having the asterisk touching the variable. http://stackoverflow.com/questions/2452335/asterisk-sometime...

My take on this has always been the pointerness is semantically part of the type, but syntactically it belongs with the variable.

Therefore I annoy both parties by putting a space on either side to protest the fact that everyone is wrong.

It's pretty easy to convince yourself that "* with the type" is wrong when you see this:

int* a, b; // a is int* but b is int

Bingo, that's the exact reason to pair the asterisk with the variable name. Especially in C-family languages where you can actually end up with code that compiles and even works, until it breaks. Think pointer arithmetic on something you assume is a pointer to a signed integer...

C has a sort of declaration-by-example syntax. You're declaring that *someVar has type NSString. (IMHO, thinking of it this way also makes more complex declarations like function-pointer types, types with qualifiers, etc., easier to read.)

You don't have it wrong. In an object-oriented context, whether you're working in C, C++, or Obj-C, it is entirely reasonable to attach the asterisk to the type name, and treat `MyObject* ` as a type.

For every weird little edge case where `MyObject* ` doesn't make sense, there are hundreds of examples where it makes complete sense.

I've been doing it that way since I started in the 90s, and I've always felt the people who do it the old way (attaching the asterisk to the variable name) are either holding on to an obsolete bit of antique C style, or they don't know what they're doing. It has no place in modern object-oriented code.

So what about `int* a, b, c;`? Never declare multiple variables on one line like this.

That's how it feels, but the syntax for declaring multiple variables breaks it:

    int* a, b;

is equivalent to

    int *a;
    int b;

not

    int *a;
    int *b;

So while I think it makes sense to think of the pointer nature as part of the type I stopped using it as the risk of writing incorrect code was too great.

Though there's also the option of forbidding shorthand declaration. Then you can write

    int* a;
    int* b;

especially if you have a linter letting you add such a syntax rule.

Given the numerous advantages of int* a; rather than int a;, and the general laziness of declaring variables together anyway, wouldn't it be more reasonable, as a house style, to require int and to disapprove the declaration of multiple variables in the same statement?

Sure. And as I noted, you may even be able to configure your linter of choice to handle that automatically. There's also the macro option, I guess.

Note: using % instead of * below because I can't for the life of me figure out how to type an asterisk without it being used as an italics markup directive.

>> Given the numerous advantages of int% a; rather than int %a;

Care to elaborate what 'numerous advantages' there are to use int% a instead of int %a, because I can't think of a single one besides 'it feels more natural', which IMO is irrelevant in the context of a coding style.

Enforcing a single line for each variable declaration does not sound like a good idea, in mathematical code this can quickly grow unwieldy due when lots of variable are involved. It also often makes sense to group declarations of related variables on the same line to indicate they are used in the same way, for example 'int v0i, v1i' to indicate two vertex indices.

The "don't declare multiple variables on one line" is a more important rules IMO, that makes the thing that's relatively unimportant (where the * is next to) go away.

i used to think like you do, but this changed my mind;

    int *a;

is saying, when you dereference a, you have an integer.

and when you think about it - a pointer is the same length for any data type, even pointers to functions, so it would be pointless to have a different pointer type for each data structure.

> a pointer is the same length for any data type, even pointers to functions

No that's not guaranteed despite being common. And function pointers are not even guaranteed to be representable by void* (POSIX08 does mandate it though.)

Relevant sections of the standard here http://stackoverflow.com/a/3941867/1546653

Here's their blog post about it: http://open.blogs.nytimes.com/2013/08/01/objectively-stylish...

Tag line: "All the Code That’s Fit to printf()"

NSLog(@"All the code that's fit to NSLog()");

It's strange that NYT seems to be transitioning to a full blown tech company. Good strange though.

It's fun working here during the transition.

Why do so many style guides mandate spaces for indentation?

It is consistent across different editors.

Deterministic layout view. Tabs are non deterministic as it depends on user settings.

Plus not all tools can ignore whitespace changes (so indentation changes everywhere intermixed with actual code changes drown the code stuff), and if your codebase mixes whitespace-significant and whitespace-insignificant code...

Mainly it's that you don't want to mix both spaces and tabs — you want to use one or the other for a given file or else the indentation will be an incoherent mess from one machine to the next — and it's easier and more compatible to standardize on spaces than tabs.

the right way to use tabs (tabs for indentation, spaces for alignment) needs some amount of discipline to get right always. It's more flexible but very easy to make a mistake and mess it up.

Agreed. But doesn't it take discipline to follow a coding convention in general? I'd argue learning tabs-indent/spaces-align is easier than following most other semantic conventions (e.g. what constitutes a good name, how to organize code).

Python really gets murderously difficult to debug in an organization with multiple types of indentation. Spaces are the least easy to screw up there, and has been why many guides I've seen have "spaces" instead of "tabs" as the default.

Because tab/space inconsistency causes problems, and because the space bar is easier to use in the flow of typing, so a style guide that mandates tabs will end up with lower compliance than one which mandates spaces.

I see a lot of obsession with the irrelevant: when you're allowed to use dot-notation, number of spaces for indentation (sic), etc... The only reasonable item, it the singleton one, the rest... what a waste of time!

Yeah, there is no value in consistency.

Has anyone ever tried to configure uncriustify [0] with a complex style guide like this and succeeded?

Are there other similar tools that might be a better fit?

[0] - http://uncrustify.sourceforge.net

They seem to have an en dash between Objective and C which made me misparse the title. Surely that's not in their style guide?

Fixed. Thanks for reporting that.

why not provide a post-commit hook enforcing a lot these styles?

We've got some people here working on it.

Reply on news.ycombinator.com