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.
> There was a code style which stated null checks should have taken the
> form of if (null == variable) which coming from Java I said was
> unnecessary however it turns out that due to .net support for implicit
> casts there are some fringe cases where if (variable == null) will
> behave differently to if (null == variable) apparently. Most of the
> developers used if (variable == null) though in spite of the coding
> standard because it was more intuitive.
>
>
I think this originates with checks against literal values instead of
against null when using value instead of reference equality.
So ("xxx".equals(someObj)) would be fine, whereas (someObj.equals("xxx"))
could throw an NPE if someObj were null.
The usual workaround here is to then always put the literal on the left hand
side of the equality check; for the sake of consistency it then makes a lot
of sense to also do the same for null and for reference equality checks.
> On May 3, 11:31 am, Moandji Ezana <[email protected]> wrote:
> > On Tue, May 3, 2011 at 10:40 AM, Casper Bang <[email protected]>
> wrote:
> > > I used to use underscore in Java code, but got
> > > converted and aligned over the years by the conservative Java
> > > community.
> >
> > I thought using the underscore was more conservative than not using it.
> >
> > In JavaScript, the underscore is often used to indicate private members,
> > when you're feeling too lazy to implement function scopes.
> >
> > Moandji
>
> --
> 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.
