When you need to make a reference to this, always use "self".
var self = this;
Don't use "me", "_self" or my personal worst, "that" (how can this ever be equal to that?). Adopt the convention and stick with it.
So what's wrong with using _self ?
So what's wrong standardizing to self?
@mauris Nothing. That's my point - you should use "self".
@darkmantiscs If we are to adopt a convention, I personally prefer "self" over "_self", given the concept of private variables (which the underscore denotes) doesn't really hold when creating a reference within individual functions.
@iwootten I was writing to @darkmantiscs not you :D
Don't get me wrong, I don't really mind, I see what you're saying about the private variables, but I was just asking to see what the reasons were, and that explains it :)
"self" doesn't seem correct. I think we should instead use the name of the caller or something like the name of the caller.
Say your object is an Article, if you're going to lose the scope of "this" then write this:
var article = this;
If you're dealing with an object like:
then do this:
var menu = this;
That makes way more sense to me.
@gagege self provides a conventional approach for use within all objects, it's understood by whoever reads the code. Using the classes object name instead makes for less readable code. If I'm looking for a reference to the class that I'm in, I wouldn't expect to see the name of it as it's own reference.
@brillinfo On the contrary, I don't think it makes it less readable at all. If I use the caller's name, I know exactly what I'm dealing with. "menu.open()" is a lot easier on the brain than "self.open()".
The problem I have with "self" is that it doesn't mean anything. If you use "self" you have to go look at who called the function, which mean possibly scrolling up a few hundred lines or going to a different file.
My method instantly tells me who the caller is. I don't even think about a "caller" actually. I just think "I'm making this object do this."
Also, if we use self, what should we do if we want another callback? Write "self2"? ;)
Edit: Let me add one more thing. When you're in a callback or closure you're no longer in the class you were in. You're in no man's land, that's why you can't use "this" anymore and it's why I have no problem using the name of the object as a reference to the object. That's how I think of it, anyway.
@gagege I guess my original point is related to a singleton based approach, where you would have a single reference to this. More the point was the generic term that's used in those cases.
Unless you have several different classes described in 1 file, you'd have no need to backtrack through hundreds of lines of code to determine what class the file you're currently in is.
I believe the accepted convention is "that"
Remember, Crockford is just a man.
var x = this should be considered a code smell. My 2 pence.
I'm not a fan of self, I much prefer var _this = this
@professorsloth Where large businesses are concerned and different development strategies exist, it rarely is that simple.
@stevefrost Oh, Steve - just confuse matters why don't you?
I agree. self is the only acceptable var name. We only use
in all out Node.js code and backbone code.
Let me summarise:
"Why not 'that' or '[caller]'?"
If you're skimming a function and you see operations being performed on a variable called 'that' or 'menu', then you immediately start wondering what 'that' or 'menu' actually is and you have to find the assignment to work it out, which takes time and is annoying. 'that' gives no clue to what it might be, and you can't be sure whether 'menu' is THIS menu, or another one. 'self' makes it obvious. All variables within readable code should offer an obvious association, imho.
As @iwootten says re: this and that, "in common vernacular they're opposites". When we talk about readability of code, common vernacular contributes heavily.
"Why not 'self' or 'this'?"
Underscored properties are generally identifying private properties.
Lexical closures are considered to be units of work in themselves, with useful references to "closure-global" variables. (I just coined that term - as far as the scope of the closure is concerned, the variable is global being defined outside of the scope but still accessible).
So, in the case of a lexical closure, how can you be using the private property of another function? I know that this is in fact what you're doing, but it's confusing nonetheless. I'd rather retain the underscore for strictly private variables.
@professorsloth I think it helps to have a universal standard rather than a team-scoped standard. Your team won't always be your team, and it won't always be your team on the project. People come and go - particularly contractors. People swap among projects in larger companies. If a company has several development teams, you'd have to ensure that your standard is adhered to by ALL teams and taught to any new starters.
I guess this is where tools like Sonar, and general code reviews come in handy.
It is interesting how varied the opinions are on this one small subject :)