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.
Such as wParam in Windows programming, originally a word (16 bit unsigned), but now an unsigned 64-bit integer on 64-bit versions of the OS, they're still stuck with the increasingly inaccurate name as it's deeply embedded in the API. In my ideal world... as we see more developers embrace immutability, and languages adopting ideas like the uniform access principle, and Scala's unification of constructor params with member values, we'll see less need for this sort of disambiguation in the future. > -- > 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. > > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
