Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Tue, Mar 06, 2012 at 07:13:47PM +0100, Alex Rønne Petersen wrote:
> On 06-03-2012 19:08, H. S. Teoh wrote:
> >On Tue, Mar 06, 2012 at 05:38:09PM +0100, Adam D. Ruppe wrote:
> >>One of the stumbling blocks on using std.datetime is how
> >>many bizarre abbreviations it has.
> >>
> >>auto time = Clock.currentTime(); // bzzt, wrong
> >>
> >>if(time - something>  duration!"hours"(4)) // bzzt, wrong
> >>
> >>writeln(time.toISOExtendedString()); // bzzt, wrong, but this used
> >>to work!
> >>
> >>
> >>
> >>Why aren't we using real words here? Real words are easier
> >>to remember and easier to type.
> >[...]
> >
> >I have to disagree on this one. One of the reasons I hate Java so much
> >is because of its gratuitouslyOverlongFullySpelledOutVariableNames. I
> >mean, it takes almost the entire line of code to just refer to a
> >variable, let alone do anything useful with it. There's nothing wrong
> >with using abbreviations... BUT they have to be *consistent*.
> >
> >I do agree with you that arbitrary abbreviations are very bad. One
> >module abbreviates "current" as "cur" and another module uses "curr". I
> >agree that's very bad. We do need to standardize on these things so that
> >they are consistent.
> >
> >My stance is that variable names *should* be abbreviated, but within
> >reason, and abbreviations must be *consistent*.  Shortening loop indices
> >to i, j, k is OK, because we know what they mean. However, renaming,
> >say, "hours" to "i" is bad. On the other hand, spelling out
> >"dayOfTheMonthExceptInLeapYears" is bad too. There needs to be a
> >balance. Which is where consistency comes in, because if "balance" means
> >"arbitrary point between two extremes", that doesn't work either.
> >
> >The sec/seconds arbitrary switch as somebody pointed out is an example
> >of inconsistency. It causes confusion and makes it hard to remember. But
> >if seconds was *always* abbreviated "sec", then there's no problem at
> >all, and it's easier to type too.
> >
> >IOW I don't think abbreviations would be that big an issue if it weren't
> >for the inconsistency. The fault is with inconsistency, not with
> >abbreviations.
> >
> >
> >T
> >
> 
> You're arguing about variable names while the original post was
> about function names. IMHO you should not conflate naming of these
> two; the former is about locally scoped symbols while the latter is
> about publicly exposed APIs.

The same rule applies. Function names should not be overly long,
especially if they are limited in scope (say, class methods). The
general rule is that the wider the scope of a name, the more unambiguous
it needs to be. (And unambiguous doesn't necessarily mean longer.)

Anyway, names like Clock.currentTime() are too long, IMO. There's
nothing wrong with shortening it. But the abbreviations need to be
consistent, so it shouldn't be currTime in one case, and curYear in
another case. And consistency needs to be across the board.


> (Also, seriously, I think you're over-dramatizing the Java variable
> naming thing; I rarely see names that are as bad as you claim...)
[...]

OK, I exaggerated a little. :-) But my point stands, that I find many of
these names just way too long for my tastes. Like BufferedOutputStream.
Or ByteArrayOutputStream.  Ugh. I mean, we're writing programs here, not
essays. Why spell things out in full if we don't need to?


T

-- 
If you think you are too small to make a difference, try sleeping in a
closed room with a mosquito. -- Jan van Steenbergen