NYTimes Objective–C Style Guide (opens in new tab)

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.

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.

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

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

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.

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.

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.

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

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

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.

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

It's fun working here during the transition.

It is consistent across different editors.

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

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.

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.

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.

Yeah, there is no value in consistency.

Fixed. Thanks for reporting that.

We've got some people here working on it.