Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NYTimes Objective–C Style Guide

github.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: NYTimes Objective–C Style Guide

#31

Post by w0utert »

taspeotis wrote: post #25
5teev wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: NYTimes Objective–C Style Guide

#32

Post by w0utert »

davidkclark wrote: post #7
srik wrote: post #2

> 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"?

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

Re: NYTimes Objective–C Style Guide

#33

Post by masklinn »

srik wrote: post #2

> 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"?

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.

Re: NYTimes Objective–C Style Guide

#34

Post by SeanLuke »

masklinn wrote: post #33
srik wrote: post #2

> 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"?

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 h…

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?

Re: NYTimes Objective–C Style Guide

#35

Post by rimantas »

frr149 wrote: post #29

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.

Re: NYTimes Objective–C Style Guide

#36

Post by masklinn »

SeanLuke wrote: post #34
masklinn wrote: post #33

Earlier quoted context omitted.

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 h…

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.

Re: NYTimes Objective–C Style Guide

#37

Post by masklinn »

jyap wrote: post #18
valtron wrote: post #8

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

Re: NYTimes Objective–C Style Guide

#38

Post by w0utert »

SeanLuke wrote: post #34
masklinn wrote: post #33

Earlier quoted context omitted.

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 h…

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?

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.

Re: NYTimes Objective–C Style Guide

#40

Post by foxhill »

srik wrote: post #2

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

Post reply on HN