NYTimes Objective–C Style Guide(github.com) |
NYTimes Objective–C Style Guide(github.com) |
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. applicationDidLoad:withANotification:iWonderWhatTheWeatherTodayIs:LetsAskSiri: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.
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.
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"?
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.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.
Therefore I annoy both parties by putting a space on either side to protest the fact that everyone is wrong.
int* a, b; // a is int* but b is int
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.
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
Deterministic layout view. Tabs are non deterministic as it depends on user settings.
Are there other similar tools that might be a better fit?
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.
>> 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.