Hi Rory,
<snip>
1) I wouldn't hire anyone who couldn't figure out that RtnVal didn't mean
ReturnValue. Readability is good, but shorter names, in conjunction with
appropriate comments can be even better.
</snip>
Agree with first sentence. Totally disagree with the second. But that is fine. We experience differing code-base and have different tools / colleagues.
<snip>
2. The use of long names often forces expressions to span multiple lines,
which can be harder to read (less usable).
</snip>
This is disputable, but there is no point disputing it. Also, the 80-byte restriction debate will flare up again. :-)
<snip>
As far as ContentAssist etc. goes, that's great *if you use WDSc and
ContentAssist*. If you don't, then long names are a real pain.
</snip>
We use RDi and Content Assist. If I had to hand-type my variable names in SEU I'd probably not like long variable names either - but for reasons of expedience not for any belief that short names are better.
But we didn't like using long variable names in SEU so we bought RDi as it has Content Assist. We favoured that solution over forcing ourselves to like short names because we are stuck with SEU. :-)
<snip>
Personally, if I saw "rateEffDate" (ideally in conjunction with some general
program documentation and comments), I'd know what it was. If you'd care to
send me a list of shorter names, I'll have a stab at figuring them out - I'm
pretty sure anyone on these forums would do a very good job, even in the
absence of any context.
</snip>
I would like to thank you for so eloquently proving my point. Your paragraph above has such things as "have a stab at figuring them out" and "would do a very good job" when decribing the process of deriving the meaning of a variable name. These moments of uncertainty are EXACTLY what I'm saying is avoided by using full descriptive names. We already have enough work, we don't need to waste time "having a stab" at the meaning of every variable name we come across.
<snip>
To me, the (over-)use of long variable names could equally signify that
those developers just don't like writing comments. I know, I know,
"self-documenting code" and all that. But is this
// Calculate rate effective date
if rateEffDate < currDate or rateEffDate >= prevEffDate;
rateEffDate = currDate;
endif;
really worse than this:
if RateEffectiveDate < currentDate or
RateEffectiveDate >= PreviousEffectiveDate;
RateEffectiveDate = CurrentDate;
endif;
</snip>
My point is not only that RateEffectiveDate is easier to read than rateEffDate. That talks to readability. My point is also about the fact that rateEffDate could easily have been rteEffDate, rateEffDat, etc... whereas there is only one possible RateEffectiveDate.
<snip>
I'm an SEU user and I'm likely to stay that way.
</snip>
I was a SEU user too - for many many many years. We paid significant dollars to move our 25+ developers over to RDi. It was an investment and it was worth every cent.
We talk of productivity. Our shop used SEU for years. We moved over to WDSCi a few of years ago and bought RDi last year. From our experience of all three products we would continue to invest in RDi and move over to RDP and NEVER go back to SEU.
<snip>
p.s. "A slight but welcome over-compensation methinks - the compiler team
equivalent of buying a sports car at 40. ;-)" Hmmm. I bought my first
motorcycle at 38, so maybe I have some personal growth issues of my own ;-)
</snip>
I bought a tractor mower at 38. What does that say about me??? :-)
(although I'd moved to Australia by then, and the lawns here are MUCH larger than those in England. The handy drink (beer) holder helps!)
Cheers
Larry Ducie
_________________________________________________________________
View photos of singles in your area! Looking for a hot date?
http://clk.atdmt.com/NMN/go/150855801/direct/01/
midrange.com
