Sign in to follow this  

Pointers: "type* var" versus "type *var"

This topic is 663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What conventions do you guys use for pointers, when and why?

type *name and type &name
- OR -
type* name and type& name

I'd like to hear what you guys like to do and why you prefer one thing over another. I'm asking these weird questions because I'm self-taught and experience a lot of people using either convention or even both, depending on various personal criterias. My eyes are practically bleeding from all the interchanged uses.

And then you got type** name and T&& name. Aaaargh!

Thanks. smile.png

Edited by Madolite

Share this post


Link to post
Share on other sites

...higher danger of accidentally going 'type* var1, var2;' and not declaring what you expect to declare. I am however strongly opposed to declaring multiple variables in one line..

I prefer a linebreak between variables as well.

Edited by Madolite

Share this post


Link to post
Share on other sites

I do whatever the nearby code does in general. next to the type, next to the name, or even with space on both sides, it really doesn't matter to me.

 

I tend to slightly prefer putting the * or & next to the variable.

Share this post


Link to post
Share on other sites

Personally I use type* var, because I feel like it's part of the type and I find it aesthetically more pleasing, but one could argue it's more clear and more consistent to write it next to the variable name because:

int* a, b;

Here a is a pointer, but b is not.

 

Put next to the variable name makes more sense here:

int *a, b;

This makes it clearer that a is a pointer and b is not and it's also more consistent in case b were to be a pointer.

Share this post


Link to post
Share on other sites

 My eyes are practically bleeding from all the interchanged uses\

 

The sooner you get used to this the better; in the grand scheme of things this is yet another one of those pointless decisions that only matters because it's important to make a decision and stick to it.

 

I'll get used to it, but it's just nice to get some explicit opinions on the matter. smile.png

Edited by Madolite

Share this post


Link to post
Share on other sites
I put it wherever the relevant coding standard tells me to.


Seriously, this isn't worth an opinion poll. Everyone has different styles and someday you'll have to adjust to at least one way of doing things that you don't like. My own "personal" style even changes depending on what code base I'm most heavily editing on a daily basis.

Just be consistent within a single code base and nothing else matters.

Share this post


Link to post
Share on other sites

This has been coming up a few times a year for decades.

 

The C convention is to put the dereference operator next to the variable name (int *a) to show that, when dereferenced, the variable a is of type int.

 

The C++ convention is to group emphasize the type (int* a) to show that variable a is of type pointer to int.  C++ puts more emphasis on type because it's a more strongly-typed language than C, although it's all relative.

 

People who write C code to be compiled by a C++ compiler usually use the C convention.  Bjarne Stroustrup discusses these conventions in his seminal reference work "The C++ Programming Language" (and several other works), why they're used, and which he prefers.

 

If you're writing C++, I would suggest you lean towards the "std::string const& var" convention, it will make understanding templates and compiler error messages a little easier.

Share this post


Link to post
Share on other sites

If you're writing C++, I would suggest you lean towards the "std::string const& var" convention, it will make understanding templates and compiler error messages a little easier.


I have been playing around with that style (and some other changes from my usual routine) for a new code base at home. It took some time getting used to but it really has grown on me and I caught myself slipping into it at work several times.

Share this post


Link to post
Share on other sites

I use "type *name", but there's no real reason or thought behind it: it's just the way I learned it and the muscle memory has stuck with me; on the other hand the vast majority of my programming work since then has been with languages where this is completely irrelevant, as in either no pointers or use of pointers even more heavily discouraged than modern C++.

Share this post


Link to post
Share on other sites

type* name because it is part of the type. I think to do this:

type *a, b;

It's better to have it by the name BUT I think it's probably bad practice to do that instead of:

type* a;

type b;

 

I do sometimes slip into my old ways of type *name but I was easily convinced by the argument of "It's part of the type" so I stick with it. I wonder is there a good argument for the other choice? Other that because the coding standard says so of course.

Share this post


Link to post
Share on other sites

These days all I see in other people's code is var * type? Apparently some programmers are fed up with being told where to put the space and put it on both sides of the asterisk. laugh.png

 

As for my opinion, I think all has been said: var* type unless you are declaring multiple variables on one line.

Share this post


Link to post
Share on other sites
I use "type* var", unless code I'm working in follows a different convention.  That's true for about 99% of programming minutiae like this.
 
My reasoning for "type* var" over "type *var" is that "type*" is the full type of the data being referenced.  Saying "var is a variable that when dereferenced is a <insert type here>" sounds ridiculously circuitous, even if there's historical logic behind it.  As for the associated "type* foo, bar" fubar (heh), I never declare multiple pointers (or usually even variables) on a single line, and in fact I've been known to modify existing code to avoid that (as well as the unblocked single-line if-statement) If I'm working in the same scope.
 
On a side note, how the heck do you format in-line code like that?

Share this post


Link to post
Share on other sites

I use Type* var.

But I am also a syntax nazi, and I do not tolerate multiple variable declared at the same line, so is not real issue for me (what about other code? Automatic re-factoring!).

The only exceptions are loop variables, but if they become a mess I put the loop into a new scoop (made only for it) and throw the variables between the opening of the scope and the loop.

Share this post


Link to post
Share on other sites

I'm an int * foo guy all day long!

You're multiplying int by foo? 

 

Seriously though, I'm with ApochPiQ. Just use whatever the code is already using.

 

Even more seriously, I'm with Hodgman and anyone who uses anything other than type* var is a terrible human being and should be ashamed. laugh.png

Share this post


Link to post
Share on other sites

on further contemplation, it would seem that type* var is more explicit, as originally noted by Bitmaster, and echoed by may others.

 

but then you must declare int and int* variables in separate statements.

 

but the whole argument of "this is an int, and this is a pointer, and they are different types", is quite valid.

 

so declarations of each type in separate statements would be more explicit, increasing read-ablity. or perhaps understand-ability, at the expense of wordiness.

 

which would mean that for the sake of increased read-ability, type* var would be the "better" convention.

 

and code with greater read-ability is usually considered "better" code - with optimized code.excluded of course. 

Share this post


Link to post
Share on other sites

This topic is 663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this