this. - code consistency and readability

Newbie & Debugging Questions
#1

Hello again,
Since I learned about classes and their internal reference this, I wondered if you would use it always when you mean it.
Consider the following Class of a program:

public class NarcissisticClass{

    public Boolean lookingGood = true;

    public void stillLookingGood(Boolean lookingGood){
        this.lookingGood = lookingGood;
    }

    public void invertLookingGood(){
        this.lookingGood = !this.lookingGood;
    }

}

The method stillLookingGood(Boolean lookingGood) actually requires you to use “this.”. invertLookingGood(), on the other hand, does not need it. You could also just reference to the variable lookingGood.

I thought: Ok, being consistent and making everywhere clear, what I am referencing to, must be a good idea. Damage done and I am lost in a jungle of looooong expressions when writing advanced mathematical calculations. There you might use a relevant amount of global variables of the surrounding object and other objects as well. So, could it be that less is more in these situations? Should I just neglect writing this. if the compiler already knows what you mean? What is more important for other programmers or for yourself after not watching the code for maybe years: The consistancy of always knowing, that you mean this.variable or the general readability of code blocks?

#2

IMO, use this only when required. I often use parameters with the same names as fields, eg in setters. Use your IDE to color parameters differently from fields. It isn’t hard to see what is going on.

#3

My Humble Opinion:
Consistency is one of the most important features of readable code. Overly long expressions are just confusing and detract from readability. That seems contradictory, but is very possible to harmonize. What I do, is reference local fields with this in constructors and setters, and in any other methods I make sure that I never create parameters with names which hide local fields. So basic, boilerplate code is very clear and follows the same format but more complex methods are also very readable.

#4

I’ve always considered using “this” everywhere bad practice. It makes it harder to visually scan the code for instances of a variable/function call. Granted, pretty much every text application has a “find” function in it, but that can be cumbersome when just concentrating on a small segment of your code as opposed to looking for all instances of something.

As a side note, I also tend to avoid giving function parameters the same name as class member variables. My implementation of NarcissisticClass would probably have the member variable named “m_lookingGood”. My secondary reason for doing such is that it groups all of my class member variables together in my IDE’s class navigator pane.

Those are just my opinions though. Your mileage may vary. Code consistency is a good thing, code repetitiveness, not so much. 8)

#5

I prefix member variables with ‘m_’ for this reason. Some people use ‘_’

I don’t think you should have to be creative with names to avoid name collisions either (I usually see this in code that avoid the m_). Alternately, you can just use ‘this’ everywhere (seems messy to me though.)

#6

Ok, I will try to add a small prefix to every member variable from now on and see where it takes me.

Thank you for your response!

#7

I would not use “m_” prefix in Java – it’s considered really bad practice and for the most part your other programmers will hate you. :wink:

Let your IDE handle this with syntax coloring. Using “this” is fine and even encouraged to increase readability. And obviously the boolean (which is lower case, not the object!) should use a more standardized setter/getter, like setLookingGood(boolean) and isLookingGood(). If the user wants to invert the boolean, they would then use [icode]setLookingGood( !isLookingGood() )[/icode]. I would only deviate from these if the class really needed it for convenience or usability.

#8

Or just this:

public class NarcissisticClass{

    public Boolean lookingGood = true;

    public void stillLookingGood(Boolean look){
        lookingGood = look;
    }

    public void invertLookingGood(){
        lookingGood = !lookingGood;
    }

}
#9

prefixing m_, etc, is so 90’s. It’s considered bad code even in C++.

#10

I often forget, how to write the boolean when I am switching between the languages.

But now you made me hesitate again which way to use. I really like to give all input parameters easy-to-understand names which includes both the object members and the local ones from the methods. I don’t really get why it is considered bad coding style to use prefixes like “_”. In Python you are even encourage to do somethign similar. In the end, it seem to be best to let the IDE or editor color the code for everybody. If and only if there is a lack of good variable names, it would be viable to use prefixes.

EDIT:

Not in all languages. In Python they are often used with a silent agreement of a meaning.

#11

In loosely typed languages like JavaScript and Python, it is common to use “_” as a prefix to suggest “private” – as in “do not touch.” Also, these languages do not have the same IDE tooling, and so syntax changes like prefixes become more common.

In Java, we can actually declare a member as private, and our IDEs know when it’s an instance or class member.

You are asking about best practices… Best practice is to stick to the language’s conventions… Which means no prefixing in Java. :wink:

EDIT: Also note, in Python, underscore prefixing is actually an official standard and part of the language. Wildcard import statements skip underscore-prefixed members.

#12

I don’t think that is true at all. There is absolutely no way to justify accidently overlapping scopes because you haven’t employed a proper naming convention and you can say ‘only some variables might be hidden’ at best regarding the code. Then you can at best be forced to always use the ‘this’ indirection due to the unpredictable nature of variable naming. You are intentionally & explicitly throwing away a scope that you are naturally placed into every time.

It is controversial I agree, but I’ve seen lots of code do it either way.

Android source guide-lines encourages the m prefix on private non-static member variables as well for Java:
http://source.android.com/source/code-style.html#follow-field-naming-conventions

#13

You use “m_” in Android because Android code uses it. Avoid the hell out of it everywhere else. The scope you’re naturally placed into is the exact reason you don’t treat it as “special”. You don’t name locals with “l_foo” do you? If your variable naming is “unpredictable”, you have much bigger problems.

#14

Indeed. That is a pretty shallow way to derive the point in my argument though.

Ofcourse member variables are ‘special.’ They are accessible by every member method in the class and they shed their scope upon every member of the class. You don’t treat your member variables like local variables, do you? I can name a million other differences with the way people handle the two.

They are unpredictable in that, if you have are accessing member variables without a naming convention, you must constantly assure yourself that the addition of member variables does not conflict with others in inner-scopes and that the addition of variables inside of inner-scopes does not collide with that of a ‘god’ scope with the exact same naming convention. You are thus forced to always use this indirection.

The difference is that when someone is writing a method it is easier to take the context of just the method rather than the context of the entire class at the exact same time. If you have an inner-scope inside of a method you can’t honestly compare the size of its scope to what a typical class sheds over its members.

It gets even messier with inner-classes as well. Inner.this.bluhbluhbluh /redundant .

#15

If you always declare your input args to a function as final (which IMHO everyone should do, at least for primitive types) then you’ll get an error if you accidentally forget the ‘this.’ in the assignment.

For simple setXxx() methods it’s often the style to have the arg name identical to the member name. That’s helpful because you’re hinting at the reader that it’s supposed to be a straightforward ‘set’ with no translation, adjustment or other monkey business.

I generally only use ‘this.’ at times when I want to emphasise that the code is changing the object’s state. Particularly when you’ve got a bunch of calculation on local values, then you set the result as a member.

Your functions should (usually) be small enough that you don’t need m_ or ‘this.’ to make them readable. And if you use ‘this.’ everywhere then you loose the ability to make people sit up and notice when one actually appears.

#16

As a NetBeans user I take full advantage of warnings, autocompletion, and templates. You can make scope errors or redundant assignments (x = x instead of this.x = x) get highlighted as warning or errors, so it is not a practical problem. You can automatically generate getters, setters, and constructors if you declare your fields first, so it’s not a problem. The default parameter name is the same as the field name and it uses this.

I prefer that parameter names, field names, and method names following “get”, “set”, and “is” all be the same. It’s more readable when other people do it because it is consistent. It also helps NetBeans guess what variables to use as parameters if the names are similar. If you don’t want to use this for some reason, the style below can be an alternative. (I think it just makes code more confusing.)

public void setColor(Color newColor)
{
  color = newColor;
}

“this” should be avoided where its redundant because long code just creates more work for yourself and other programmers. An exception might be for equals and compareTo methods. I usually have code like “if(this.color != other.color) return false;”

If you prefix (or postfix) anything, then do so with the parameter names. Prepend “new” or _ or append a 0 or _.

#17

“Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.”
Java Code Conventions

Just sayin’. If you want to follow best practices, then follow the language’s conventions. This becomes really important when you are in a large team or writing software that might be used by many other programmers.

Android SDK has its own style guidelines, which are important to follow. If you don’t strictly follow their whitespace, use of braces, naming conventions, logging, etc. then your contributions will get rejected. Note that these naming conventions are specific to Android SDK contributions and patches, and rarely encouraged anywhere outside of that.

#18

True.

The right answer here is use whatever style guidelines are set out by your team. If you haven’t established one yet, then be consistent with what you have already.

#19

And it’s my assertion that they’re precisely not “special”. They’re variables in object scope. Go look up the concept of “static closure” sometime (you’ll have to do better than Wikipedia though, which does a lousy job at it). You can wave your hands and say I’m up in some hoity-toity theoretical ivory tower, but then go ask yourself why they didn’t make ‘this’ mandatory?

#20

Not in the eyes of the compiler, anyone can create a scope anywhere they want.

They are ‘special’ in the eyes of programmers since they do have a particular significance and there are extra considerations not carried by local variables that need to be taken in to account when designing the class.