Code:
//Using src.icon_state Problem description: Is it better to use src.icon_state (or src.variable for that matter) or just icon_state? Both result in the same thing but I was just wondering which is better to use. | |
Unless there is a scope issue--e.g., a local proc var with the very same name--you should always use varname instead of src.varname. It's cleaner and clearer. Internally it won't make any difference to the way your game performs, since it compiles the same either way.
Whenever I see code littered with "src.var" lines, it's a clear indication that the developer has trouble telling when to use src, usr, or another object. This is also a great way for old misuses of usr to slip in undetected, since usr.varname may not catch your eye in a proc full of src.varname lines. By avoiding the src.something construction, any time you see thing.var it jumps out at you. | |
Ah I see thanks for the advice guys
| |
I'm a little late to this discussion, but I wanted to add in my reasoning as to why I still qualify all variable/procedure calls with src. I'm used to other languages such as JavaScript or C++ that use this frequently (see also: Python's self). It's just a habit that I transferred over to DM.
| |
LordAndrew wrote:
I'm a little late to this discussion, but I wanted to add in my reasoning as to why I still qualify all variable/procedure calls with src. I'm used to other languages such as JavaScript or C++ that use this frequently (see also: Python's self). It's just a habit that I transferred over to DM. Yes, but using this->var in C++ when there's no scope issues to worry about is every bit as much of a readability killer. C++ will always default to this->var when accessing a member if there's no local name that conflicts with it. In JavaScript I understand it's a necessity; the way that language works, a name is always assumed to be local (to the current function or else upwards in the closure stack) or global unless you tell it otherwise. That's an unfortunate reality of the language, but not at all something worth emulating in languages that don't suffer from that problem. | |
Awh man, so this is another bad habit I need to ditch?
| |
Awh man, so this is another bad habit I need to ditch? Not really. The only time you NEED to use src is for a namespace conflict. Otherwise, it doesn't make an actual difference in DM because variable accesses in DM compile with explicit scope. "src.herp" and "herp" will both compile to ACCESS [SRC] [herp] unless there is a local variable "herp", in which case it compiles to ACCESS [LOCAL] [herp]. The bytecode again, not accurate to what the compiler spits out, but represents the general idea. | |
generally where there are collisions between names, I tend to just rename one of them, for example in constructors if I'm setting say, X/Y, the arguments to the constructor will be nX and nY.
I just hate "this" , "src" and "self", even in languages that require them. | |
Lavenblade wrote:
Awh man, so this is another bad habit I need to ditch? Depends on how much you value readability. The more of my own code I revisit, the more I find myself wishing I'd commented better or used clearer conventions in a lot of places. IMO, putting src in front of every var and proc just gets messy, and messy is the enemy of clarity. But it won't make a bit of difference in how the code is compiled. | |
I just want to improve myself as a programmer, and I suppose that will make my work more readable so I guess I'll start changing my ways. It'll definitely help for when I work on projects with others or anything open source.
| |
Also if you are using local variables with the same name as an src variable (which is normally bad to do because it is more likely to make a mistake with it that way), you have to use src. to specify you want to use a variable of the same name from the src and not the local variable.