What's your preferred pointer declaration style, and why?

Question

I know this is about as bad as it gets for "religious" issues, as Jeff calls them. But I want to know why the people who disagree with me on this do so, and hear their justification for their horrific style. I googled for a while and couldn't find a style guide talking about this.

So here's how I feel pointers (and references) should be declared:

int* pointer = NULL;
int& ref = *pointer;
int*& pointer_ref = pointer;

The asterisk or ampersand goes with the type, because it modifies the type of the variable being declared.

EDIT: I hate to keep repeating the word, but when I say it modifies the type I'm speaking semantically. "int* something;" would translate into English as something like "I declare something, which is a pointer to an integer." The "pointer" goes along with the "integer" much more so than it does with the "something." In contrast, the other uses of the ampersand and asterisk, as address-of and dereferencing operators, act on a variable.

Here are the other two styles (maybe there are more but I really hope not):

int *ugly_but_common;
int * uglier_but_fortunately_less_common;

Why? Really, why? I can never think of a case where the second is appropriate, and the first only suitable perhaps with something like:

int *hag, *beast;

But come now... multiple variable declarations on one line is kind of ugly form in itself already.

Answer 1

In C# code, I prefer the int* x; to int *x; as * belongs to the type, but in C/C++, * belongs to the variable, not the type, so the int *x; habit will be less prone to errors.

Answer 2

In C and C++ the * modifies the variable, not the type and belongs with the variable, as is proved by:

int *abc,def;

What's def, an int or a pointer?

In C# it modifies the type and belongs with the type.

In Java, there's not such notion. I don't follow your 0/NULL/null remark.

Answer 3

I think that * refers to the type and always write Type* t.

Type t;  // type is 'Type'
Type* t; // type is 'a reference to Type'

So *t means dereferencing.

Answer 4

For clarity I sometimes use tabs between types and variable names with I declare structs:

struct something_s {
    int            *foo;
    unsigned int   bar;
};

is clearer than:

struct something_s {
    int *foo;
    unsigned int bar;
};

for my eyes.

So putting the * near the variable name istead of the type is more convenient for me.

Answer 5

int* pStuff ....... pStuff's type is "pointer to an int"

int stuff ........ stuff's type is "int"

Especially true since you can write

typedef int* pInt;

pInt pStuff;

Answer 6

As long as the source code sticks to one notation or the other I don't really mind... it's when the source mixes both methods that it becomes an annoyance for me.

Answer 7

Currently living in the MFC world, where the hungarian notation is quite common, I use to handle it the same way as you, Owen.

My code then looks slightly different with pointer variables having a p prefix:

int* pFoo = NULL;

With the prefix it would simply be redundant to put the asterisk next to the variable name.

---

I also agree with you on the rule not to declare several variables on one line for some reasons:

• The obvious: No questions about the type of variables arise when declaring pointers and references.
• It encourages declaring a variable right where it's needed because one doesn't save any typing effort anyway. This helps to avoid C-style declarations at the beginning of a function, which I believe is not a good practice.
• It's easier to change the type of a variable.

Answer 8

I'm one of those "evil" guys who like the free standing asterisk. I like it because it looks best in my eyes. Of course you can argue that int* should be read as pointer to int, but this, as mentioned before, doesn't work with multiple declarations. And since we all know the common pitfalls and they also lead to compile errors and not to hidden bugs, it is simply a matter of taste and what you are used to.

char *start, *end;   // or
char * start, * end; // looks simply nicer then
char* start,* end;

And I don't think that every variable declaration belongs in its own line. In this case start and end are belonging together. But this is also a matter of taste and habit.

Answer 9

Each declaration gets it own line. I use the * symbol next to the variable.

int *pointer = new int(1);

Answer 10

According to the AV rule 62 of the JFS C++ Coding Standards:

The dereference operator '*' and the address-of operator '&' will be directly connected with the type-specifier.

Rationale: The int32* p; form emphasizes type over syntax while the int32 *p; form emphasizes syntax over type. Although both forms are equally valid C++, the heavy emphasis on types in C++ suggests that int32* p; is the preferable form.

Examples:

int32* p;  // Correct 
int32 *p;  // Incorrect
int32* p, q;  // Probably error. However, this declaration cannot occur under
              // the one name per declaration style required by AV Rule 152.

P.S. Will rules are "expected to be followed".

Answer 11

From a compiler's (or a compiler writer's) point of view, the expression "int *p" is resolved as follows:

1. Read from left to right, find the first identifier, which is "p";
2. Look right, there's nothing;
3. Look left, it's a "*", so the compiler determines that p is a pointer;
4. Look right, there's nothing;
5. Look left, it's an "int", so the thing that gets pointed to by p is an int.

That's why you see "int *p" in a lot of C code rather than "int* p". Of course, whether you should use one style instead of another is purely a question of personal taste. Like vi and emacs thing.

BTW, I recently read a lot of C code from MS. Very ugly, consistently ugly.

Answer 12

int *ugly_but_common;

is not ugly, and neither is:

int *hag, *beast;

nor even:

int witch, *ghost, goblin; // this must really confuse you.

All of them are simply saying *ugly_but_common (or *hag or *beast, or whatever) is of int type. This is not to be confused with ugly_but_common which is of pointer-to-int type. The last witch/ghost/goblin is used in a K&R tutorial (http://www.lysator.liu.se/c/bwk-tutor.html#pointers), though with less colorful names.

This is always the style K&R uses, for the reason I explained (I don't have the book with me, so I can't give a quote. Check for yourself).

Answer 13

There are lots of reasons why int *pi=NULL; is wrong and int* pi=NULL; is right:

1) int* is a type and you can typedef it as such if necessary (typedef int* INT_PTR;), then you can INT_PTR pi=NULL;

2) you *can* put multiple declarations on a line ... if you are a pathalogic idiot, but you'll confuse youself if you use a typedef as INT_PTR pi, pj; does declare 2 pointers

3) if you do int *pi; you will never be able to declare a constant pointer which must be delcared - int* const pi; or a constant pointer to a constant int - const int* const pi; (you could even type def this - typedef const int* const CONST_INT_CONST_PTR;)

QED there is only one right way, though you will get an awful lot of narrow minded whingers who will blindly defend their indefensible position - they should all be put in a special home for people with outdated skillsets :-)

Answer 14

Which do you prefer?

int[10] arr;
int arr[10];

In C (I can't say about C++ or C#), the first option is a syntax error, so I write my pointers as my arrays

int *ptr;

Answer 15

The argument that * and & modify the type as opposed to the declarator is spurious, as it is inconsistent with every other type; for example, we don't declare an object of type "N-element array of T" as T[N] a, nor do we declare an object of type "function returning T" as T() f. For something like a pointer to an array or a pointer to function, the * must be explicitly bound to the declarator as in T (*a)[N] or T (*f)(). Writing something like T* a[N] just indicates confused thinking AFAIC.

Answer 16

It doesn't matter, it is personal preference.

Some people like to keep the type together:

int* p;

Other people say that it should go next to the variable because of the following:

int *p, x;//declare 1 int pointer and 1 int
int *p, *x;//declare 2 int pointers.

Over time you will just overlook this and accept both variations.