RE: [Xerces2] Coding Conventions (warning: controversial!) - re: Paul Philion and use of this

[Chris Greenlee <CG...@demandsolutions.com>]

> am curious as to the result.  Depending on your answer, I may 
> try consistent
> explicit use in a file or two of my own and see how I like it.

Recently my company has adopted some XP practices, including pair
programming, and my partner(s) and I have found that while the
"this.attrName" can take a little getting used to at first, it does tend to
make things remarkably clear.  fAttrName and m_AttrName, while shorter,
aren't nearly as transparent to someone who hasn't read the coding
conventions document for the project.

Chris Greenlee

RE: [Xerces2] Coding Conventions (warning: controversial!) - re: Paul Philion and use of this

[Mark Diekhans <ma...@lutris.com>]

While I can certainly see the advantage of `this.' in an educational
environment, I have found that that it makes code slightly harder to read.
However, the main problem is that it doesn't solve shadowing problems, since
the compiler doesn't enforce it.  Its easy to leave of the `this.' and pick up
the wrong variable.  When I first started looking at Xerces code, I found the
`f' prefix a bit ugly.  But after being bit by one too many shadowing bugs in
one week, I started experimenting with the `f' prefix convention and found the
results rather satisfying.  It didn't add 5 characters to each variable
reference (which are long enough, due to a belief that a meaningful variable
name is worth a lot) and no more shadowing bugs.

$0.02
Mark


Elliotte Rusty Harold <el...@metalab.unc.edu> writes:
> I use this. in pretty much all the code I don't have to write to 
> someone else's coding conventions.  When I started teaching Java, I 
> noticed that almost all students had a big conceptual hurdle to get 
> over in terms of understanding the difference between static/class 
> variables and methods and instance/object variables and methods.
> 
> As soon as I started putting this. in all my example code, the 
> problem vanished almost overnight. As an extra, unintended benefit 
> students suddenly understood the difference between local variables 
> and and fields as well. It's just easier when you have one simple 
> rule (all members are prefixed by a reference) rather than a rule 
> plus exceptions (members are prefixed by a reference variable unless 
> they're referred to from a method in the same class as the member 
> except when a local argument or variable shadows the field name in 
> which case you must use this.) It's just a lot easier to understand.
> 
> Now I haven't convinced myself that this is important for experienced 
> Java programmers who already understand all these details. However, I 
> certainly haven't found typing this. to be particularly onerous in my 
> own work. Like any other convention you get used to it, and then 
> doing it any other way looks very strange.

RE: [Xerces2] Coding Conventions (warning: controversial!) - re: Paul Philion and use of this

[Elliotte Rusty Harold <el...@metalab.unc.edu>]

At 2:39 PM -0500 10/10/00, Chris Greenlee wrote:

>Recently my company has adopted some XP practices, including pair
>programming, and my partner(s) and I have found that while the
>"this.attrName" can take a little getting used to at first, it does tend to
>make things remarkably clear.

I use this. in pretty much all the code I don't have to write to 
someone else's coding conventions.  When I started teaching Java, I 
noticed that almost all students had a big conceptual hurdle to get 
over in terms of understanding the difference between static/class 
variables and methods and instance/object variables and methods.

As soon as I started putting this. in all my example code, the 
problem vanished almost overnight. As an extra, unintended benefit 
students suddenly understood the difference between local variables 
and and fields as well. It's just easier when you have one simple 
rule (all members are prefixed by a reference) rather than a rule 
plus exceptions (members are prefixed by a reference variable unless 
they're referred to from a method in the same class as the member 
except when a local argument or variable shadows the field name in 
which case you must use this.) It's just a lot easier to understand.

Now I haven't convinced myself that this is important for experienced 
Java programmers who already understand all these details. However, I 
certainly haven't found typing this. to be particularly onerous in my 
own work. Like any other convention you get used to it, and then 
doing it any other way looks very strange.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+