On May 3, 10:22 am, Kevin Wright <[email protected]> wrote: > On 3 May 2011 15:11, Alexey <[email protected]> wrote: > > > > > On May 3, 7:16 am, Kevin Wright <[email protected]> wrote: > > > On 3 May 2011 11:51, Carl Jokl <[email protected]> wrote: > > > > > When I worked at a company writing C# the coding standard was to use > > > > underscores before variables which were members of a class. This > > > > should have avoided using this.variable = variable and made it clearer > > > > which variables belonged to the class and which were local variables. > > > > The code style also said though that the this keyword should also be > > > > used when accessing variables which belonged to the class. I found > > > > that retarded and argued with the manager over development that the > > > > underscore should be used or the this keyword but not both as it was > > > > redundant. > > > > I'm curious... Why would it matter *where* a variable comes from? So > > long > > > as you know *what* it is you have everything necessary to use the thing. > > It > > > would seem to me that abstracting away the origin is desirable, as it > > makes > > > life far simpler if you should ever need to refactor in the future (hint: > > > almost all systems need some form of refactoring during their lifespan). > > > > The only exception to this is when a parameter has the same name as a > > member > > > because you're injecting the value in a constructor or using a setter > > method > > > (which would be a code smell if you're already sold on the idea of > > immutable > > > objects) > > > Given that the thing injected and the thing you subsequently reference > > are > > > identical, it seems farcical to use different names, in this (and only > > this) > > > very specific instance I'll use "this.XXX" to disambiguate in Java code. > > > I think it depends on the context (no pun intended). If you're only > > reading state from said variables, then I suppose it's not a problem > > if you don't know their true scope. But if you're ever expecting them > > to be mutated, need to synchronize on them, worry about whether or how > > the enclosing object's state is affected after the current operation, > > then understanding variable scope is critical. So if you don't wanna > > enforce coding standards on a case-by-case basis, it's probably better > > to err on the side of caution and always be explicit about variable > > scope either via their names or by using "long form": > > Person.COMMON_GOOD.giveFrom(this.cashMoney) > > This smells a lot like the widely discredited hungarian notation, encoding > the type of a variable in its name.
I don't see how this is at all like the Hungarian notation. Hungarian notation is all about always declaring variable type. In the modern days, getting the type wrong will almost always fail to compile (interpreted or dynamically typed languages are a different matter). The aforementioned example is about scope, where things often WILL compile, but will produce undesirable behavior when the scope is misunderstood. I actually think in some ways we use Hungarian notation in a more informal way, particularly when we lack static analysis. For the most part we use naming conventions to denote differences between numeric and other types. How often do you see something named peopleCount? Or how about configFileName? Like it or not, there are many explicit and implicit variable naming conventions out-there that survived years of trial and error and a variety of coding practices and have been perpetuated by way of samples and examples and now reside deep in the recesses of our programming minds. They may not be Hungarian notation per se, but when I see "Count", "Name", or "Date" variable name suffix, I tend not to have much doubt as to its type (within the context of the particular programming language). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
