Fog Creek Software
Discussion Board




this-> or no this->

Without getting into a true holy war, I was wondering if anyone had any good anecdotal reasons for including or excluding this-> in their code.  I like it for reasons of code completion; the member functions in my class just pop up once I put it in.  Without it, everything in the global namespace pops up.

The other guy at work (and the boss) doesn't like them.  He hasn't really spelled out why, he just doesn't like them.  So I continue to use them and he continues to deal with them.

"I like it" and "I don't like it" are not good reasons.

Ryan Phelps
Thursday, July 08, 2004

Readability.

secutus est
Thursday, July 08, 2004

I like using this-> because it's much clearer.  I'm a fan of having clear code that everyone can understand as opposed to saving a few keystrokes and possibly causing confusion.

saberworks
Thursday, July 08, 2004

yep, I like this-> .  It removes ambiguity.

muppet from forums.madebymonkeys.net
Thursday, July 08, 2004

Other than making the IDE easier to use because your global namespace isn't properly partitioned (which isn't your fault), are there any other reasons to use this->?

Derek
Thursday, July 08, 2004

yes, to write clear code

it annoys the hell out of me when people don't use fully qualified names.  It makes code 300% harder to read/troubleshoot after the fact.

muppet from forums.madebymonkeys.net
Thursday, July 08, 2004

Muppet, would it be accurate to say that you're not a fan of the "using" statement for namespaces?

Derek
Thursday, July 08, 2004

I suppose if you were programming in a text editor w/out code completion, this-> would be a nuisance to type in every time.  I think it's a nuisance to program w/out code completion any more.  But I guess if you're smart enough to code w/out code completion, you're smart enough to remember what member functions are in all your objects too.

Also, some people say that the code gets "too big," along the lines of every-curly-brace-has-its-own-line -- which I also do.  I guess I write "big code."

Ryan Phelps
Thursday, July 08, 2004

In that case I write HUGE code, because I use this-> (without code completion), I put curly braces on their own line, and I double space all over the place between functionally significant portions of code.

muppet from forums.madebymonkeys.net
Thursday, July 08, 2004

I like

((*this).(member))

because its arbitrarily verbose and reduces the usage of an extra operator, thereby simplifying the language.

hoser
Thursday, July 08, 2004

I prefer to put this->, that way I'm not required to put m_ and l_ prefix nonsenses everywhere in the code.

Eric V.
Thursday, July 08, 2004

Now THAT is convincing.

hoser
Thursday, July 08, 2004

I only use this-> when it is required to resolve ambiguity.

My setters and getters and such often use a parameter sharing the same name as the member variable, eg:

void SetPosition(int x, int y)
{
  this->x = x;
  this->y = y;
}

When the this-> isn't needed, I don't use it, but it also doesn't bother me if other people do use it when not strictly required.  To each his own.  There is no specific technical reason to use it or not use it.  It all comes down to your coding style and your ideas on which style is more readable and less error prone.

Mr. Fancypants
Thursday, July 08, 2004

I sometimes use it to get the IDE to list the member variables and functions of the class when I can't remember them. After typing the '>' the IDE will drop down a list box of all the members. I delete it afterwards though. I've always wanted the IDE to drop down the list box if I just type '.'. After I choose the function or variable the IDE would delete the '.' for me. I'd use that all the time.

antiparagon
Thursday, July 08, 2004

I find the use of "this->" a bit terse, and prefer to code in this style, in accordance with modern "Best Practice":

/********************************************
* Declare a pointer to point to
* the current object
********************************************/

MyClassWithAVeryLongNameToAssistInReadability* PointerToTheCurrentInstanceOfThisClass;

/********************************************
* Assign a pointer to the current instance of the class to
* the pointer variable which we've just declared
********************************************/

PointerToTheCurrentInstanceOfThisClass = this;

/********************************************
* Now do whatever it is that we want to do
********************************************/

try
{
PointerToTheCurrentInstanceOfThisClass->InvokeSomeMethodWithAVeryLongNameToAssistInReadability();
}
catch (ExceptionTypeWithAVeryLongNameToAssistInReadability& ExceptionWithAVeryLongNameToAssistInReadability)
{
PointerToTheCurrentInstanceOfThisClass->HandleTheExceptionWithAVeryLongNameToAssistInReadability();
}

/********************************************
* And hey presto, we're finished!
********************************************/

Grumpy old fart
Thursday, July 08, 2004

I prefer the style of Grumpy old fart.  However he really didn't use enough comments.  6 months from now, how the hell are you going to tell what that code does?  You'd have to rewrite it from scratch. 

free(malloc(-1))
Thursday, July 08, 2004

Originally, I started naming the members of a class 'MyX, MyY' etc.  Then, I saw the Microsoft MFC stuff all using initial 'm_xxx' to indicate members.

Found I did not like either standard.

Then, I started naming members of a class as generically as I could -- so that the object name would prefix the generic names, and give the namespace.  Thus CurPoint->X, CurPoint->Y.

When I started doing that, using this->X, and this->Y differentiates very nicely from merely local variables, and passed-in objects.  Thus the:
this->X = X;
this->Y = Y;

becomes unambiguous, and I don't have to invent new names just to tell things apart.

Since in C++, most of the member variables are only found in a .H file some lines away from where I am using them, I find the 'this->' gives me a warm fuzzy that I can easily confirm what I intended to do.

AllanL5
Thursday, July 08, 2004

I have to agree with free(malloc(-1)).  Just because the language uses such terse keywrods like "try" and "catch", doesn't mean you cannot "help out a little bit" by adding some comments for these lines.

// The following code is in a try because it might throw an exception.

and

// The following code handles exceptions cause by the above call.

Steamrolla
Friday, July 09, 2004

I know I work with some co-workers who help ME out by added this useful type of comment.

Even better:

localvar = x;    // Sets localvar to x

Steamrolla
Friday, July 09, 2004

Look, give me a break you guys - it was just a briefly sketched example. OF COURSE I'd use more comments in a production environment.

Another handy tip, by the way, is to use the preprocessor to enhance code readability- for example:

#define TryToExecuteTheCodeBetweenTheFollowingCurlyBracesButBePreparedToCatchAnyExceptionThrownByTheCode try

Grumpy old fart
Friday, July 09, 2004

Alright, Grumpy old fart, I'll give you the benefit of the doubt this time, but sloppiness in tools and examples eventually drifts into production code.

Steamrolla
Friday, July 09, 2004

Obviously that should all be on one line. Sadly this forum does not appear to support modern thinking when it comes to code layout.

Grumpy old fart
Friday, July 09, 2004

yep, I like this-> .  It removes ambiguity.

How can it remove ambiguity? It it were ambiguous, the compiler couldn't compile it!

Ignore my ignorance
Friday, July 09, 2004

Steamrolla, thanks for the benefit of the doubt. However, I personally feel that your commenting style still needs some work. As Rob Pike, a noted advocate of object-oriented programming, recently pointed out, instead of

localvar = x;    // Sets localvar to x

you should use

/**********************************
*                                                                *
* Set localvar to x                                      *
*                                                                *
**********************************/

localvar = x;

Grumpy old fart
Friday, July 09, 2004

I assume anyone who puts 'this->' is a rank amateur in C++, I've never seen anyone who wasn't fresh out of college use it. It's completely unnessecary, and needlessly verbose - the only time I ever use it is for the autocomplete but, frankly, most of the time I know what my member variables are called anyone and so should you.

Mr Jack
Friday, July 09, 2004

Hey Grumpy old fart,

    Don't do that to me, that isn't MY coding style, that was an example of the poor comments that my co-workers use.  I was clearly showing how wrong they are.  However, thank you for showing some of the newbies out there what my co-workers are doing incorrectly.

Steamrolla
Friday, July 09, 2004

Sorry people.  Using this-> makes the code unreadable, and is a waste of time. 

For methods, the name is good enough.  If you need to use a function with the same name outside of the class scope, use :: .

As for member variables, prefix them with an 'm' and you start to solve a ton of problems, especially when you look at the code months later.

Happy to be working
Friday, July 09, 2004

Ok, so that's your opinion.

I like this->

it's annoying when folks don't use it.

muppet from madebymonkeys.net
Friday, July 09, 2004

I use Eclipse and work in Java.  Eclipse lets me pick different colors for local, parameter, and field variables.  I don't have to figure out whether "conn.close()" refers to a local connection, a connection passed into the method, or a field.  The color tells me.

Why don't you guys upgrade to a modern IDE and use a modern language?  True, vi was once The One True Editor (unless your were an Emacs user), but this is 2004, not 1954.  True, C++ was once The One True Language, but this is 2004, not 1994.

(Puts on asbestos suit and waits... :-)

Should be working
Friday, July 09, 2004

I dislike modern IDEs because they allow amateurish, sloppy programmers to code with relative ease.  This is a Bad Thing (tm).  It pollutes my workplace with folks who ought not be there (folks with no attention to detail, who rely solely on their tools and would be lost without them).

While I agree that you should use the right tool for the job, and the best tool that your money can buy, you should also have a firm understanding of what it is that the tool is doing, and that trait is sorely lacking in all you "modern" developers.

muppet from madebymonkeys.net
Friday, July 09, 2004

' "Removing Ambiguity" -- if it was ambiguous, the compiler wouldn't compile it!"

Well, that may be true.  But where the compiler detects the ambiguity may be a long way away from where the coder introduced it.  This makes removing the ambiguity so it WILL compile difficult.

And if it is NOT ambiguous to the compiler, but it IS ambiguous to me, what's to say the One Meaning the compiler's syntax chooses is the one I intended?  How do you (when reading the code after the fact) even KNOW what I intended?

Ambiguity is not the enemy of the compiler.  If there's too much, it simply won't compile.  Ambiguity is the enemy of humans.  We're the ones who care if the result is CORRECT or not.  Ambiguity makes it hard to tell.

AllanL5
Friday, July 09, 2004

I've had hard-to-debug problems before that resulted from confusion between a class member and something in the global namespace. Nonetheless I don't use this-> unless it is required for disambiguation.

Incidentally, Python *requires* that class members be prefixed by "self." e.g. self.method(self.foo, self.bar). This is because Python forces you to explicitly list the "self" reference as a parameter to member functions (it would be as if every C++ member function had to include Myclass *this as the first parameter)

Dan Maas
Friday, July 09, 2004

I've found this-> useful in lowering your tolerance for overly busy lines of code. I try not to put in any spaces either -- just tabs when indenting. With no spaces and this-> everywhere, each line of code has to be much simpler in order to be comprehensible without running your finger along it, counting levels of brackets or manually breaking it apart.

After programming in Python and C, it seems confusing not to have it in there, particularly since nobody at all seems to adorn their function names with "m_" prefix or "_" suffix, but maybe I missed the bit where it became cool to use "::" for globals.

Tom
Saturday, July 10, 2004

*  Recent Topics

*  Fog Creek Home