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 -- Life would be easier if I had the source code. -- YHL
