[srik]

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

[Tiktaalik]

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

[masklinn]

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.

[gte910h]

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.

[SeanLuke]

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?

[w0utert]

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.

[masklinn]

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.

[thought_alarm]

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.

[cobbal]

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.

[wiml]

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

[davidkclark]

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

[w0utert]

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

[foxhill]

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.

[0x09]

> 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