Good programming question

java-programmer, Good programming question I was just wondering as to what is a better standard to program by. If
I have a class like this:
class MyClass {

private int myVariable;

private void myMethod1(){
myVariable = 1;
}
private void myMethod2(){
this.myVariable = 1;
}

}
Which method is better? Is there a better choice? Does it make any
difference which way I do it? Maybe this sounds like an insignificant
question but I have done this both ways and just don't know if there is
a good reason to go one way or the other.

java-programmer >> Good programming question

Altman wrote:
> I was just wondering as to what is a better standard to program by. If
> I have a class like this:
> class MyClass {
>
> private int myVariable;
>
> private void myMethod1(){
> myVariable = 1;
> }
> private void myMethod2(){
> this.myVariable = 1;
> }
>
> }
> Which method is better?

I tend to use 'this.' in setters and in the constructor
because I usually choose the parameter name to be
identical to the field name.

When using the field, I don't prefix with this, because
there is (should be!) no variable with the
same name.

Harald.

java-programmer >> Good programming question HK sez:
>
>
> Altman wrote:
>> I was just wondering as to what is a better standard to program by. If
>> I have a class like this:
>> class MyClass {
>>
>> private int myVariable;
>>
>> private void myMethod1(){
>> myVariable = 1;
>> }
>> private void myMethod2(){
>> this.myVariable = 1;
>> }
>>
>> }
>> Which method is better?
>
> I tend to use 'this.' in setters and in the constructor
> because I usually choose the parameter name to be
> identical to the field name.
>
> When using the field, I don't prefix with this, because
> there is (should be!) no variable with the
> same name.

I tend to prefix local variable names with 'f' (hangup from
Delphi days): private int fMyVariable. This way I never have
parameter names clash with local variable names, hence no need
for 'this'.

It's a matter of style. I prefere mine because sometimes you
forget to type in 'this' and get interesting errors, but
other than that there's no "better" about either style.

Dima
--
The most horrifying thing about Unix is that, no matter how many times you hit
yourself over the head with it, you never quite manage to lose consciousness.
It just goes on and on. -- Patrick Sobalvarro

java-programmer >> Good programming question On Wed, 1 Jun 2005, Altman wrote:

> I was just wondering as to what is a better standard to program by. If
> I have a class like this:
> class MyClass {
>
> private int myVariable;
>
> private void myMethod1(){
> myVariable = 1;
> }
> private void myMethod2(){
> this.myVariable = 1;
> }
>
> }
> Which method is better? Is there a better choice? Does it make any
> difference which way I do it? Maybe this sounds like an insignificant
> question but I have done this both ways and just don't know if there is
> a good reason to go one way or the other

Questions like this tend to degrade into holy wars. Better is a matter of
opinion.

For simple things and first creations it really doesn't matter too much.
The point where conventions like this matter is during the maintenance
period.

It would be rare for this to happen but what if you had the class
Bar and it referenced the variable Moo. Now in v2.7 of the product you
change Bar to extend Foo. Foo also has a variable Moo. In Bar you
reference super.Moo and Moo. All is still good. Finally, you are working
on v5.6 of your product (actually by this point you are no longer with the
company and someone else is implementing v5.6). They realize the variable
Moo is no longer needed in Bar. The variable Moo in Foo handles
everything. So you delete the member variable Moo from Bar. Did you want
to remove all the uses of this.Moo from Bar? If they are written as just
Moo they will automatically become super.Moo. Is this the behaviour you
wanted? This could be a defect in the product.

That said, I'm lazy. I don't prefix member variables with this. I like to
save myself typing the five extra characters. The chance of something
going wrong is remote. I've also dealt enough with other developers code
to think about how my changes will affect the code.

On the other hand, I've worked with development tools that typing 'this.'
brings up a list of member variables and methods. In those cases I'll
prefix everything with this just to get the help from the tools.

--
Send e-mail to: darrell dot grainger at utoronto dot ca

java-programmer >> Good programming question . wrote:
> On Wed, 1 Jun 2005, Altman wrote:
>
>
>>I was just wondering as to what is a better standard to program by. If
>>I have a class like this:
>>class MyClass {
>>
>> private int myVariable;
>>
>> private void myMethod1(){
>> myVariable = 1;
>> }
>> private void myMethod2(){
>> this.myVariable = 1;
>> }
>>
>>}
>>Which method is better? Is there a better choice? Does it make any
>>difference which way I do it? Maybe this sounds like an insignificant
>>question but I have done this both ways and just don't know if there is
>>a good reason to go one way or the other
>
>
> Questions like this tend to degrade into holy wars. Better is a matter of
> opinion.
>
> For simple things and first creations it really doesn't matter too much.
> The point where conventions like this matter is during the maintenance
> period.
>
> It would be rare for this to happen but what if you had the class
> Bar and it referenced the variable Moo. Now in v2.7 of the product you
> change Bar to extend Foo. Foo also has a variable Moo. In Bar you
> reference super.Moo and Moo. All is still good. Finally, you are working
> on v5.6 of your product (actually by this point you are no longer with the
> company and someone else is implementing v5.6). They realize the variable
> Moo is no longer needed in Bar. The variable Moo in Foo handles
> everything. So you delete the member variable Moo from Bar. Did you want
> to remove all the uses of this.Moo from Bar? If they are written as just
> Moo they will automatically become super.Moo. Is this the behaviour you
> wanted? This could be a defect in the product.
>
> That said, I'm lazy. I don't prefix member variables with this. I like to
> save myself typing the five extra characters. The chance of something
> going wrong is remote. I've also dealt enough with other developers code
> to think about how my changes will affect the code.
>
> On the other hand, I've worked with development tools that typing 'this.'
> brings up a list of member variables and methods. In those cases I'll
> prefix everything with this just to get the help from the tools.
>
Theres several coding standards you can google for. Pick a popular one
you like and stick to it. It doesnt matter so much which standard you
use so long as you have one, particularly for a large project. A
standard can be an evolving document too. If you want to tighten up
some feature, go ahead, preferably before you have alot of
non-conformant code.