On 03/06/2012 07:13 PM, Alex Rønne Petersen wrote:
> (Also, seriously, I think you're over-dramatizing the Java variable
> naming thing; I rarely see names that are as bad as you claim...)
>

It is not only about single names, but also about how many times you have to spell them out in short intervals.

try{
    SqlConstraintViolatedExceptionFactoryWrapper sqlConstraintViolatedExceptionFactoryWrapper = new SqlConstraintViolatedExceptionFactoryWrapper(new SqlConstraintViolatedExceptionFactory(...));
    SqlConstraintViolatedException sqlConstraintViolatedException = sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);
    throw sqlConstraintViolatedException;
}catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
    // ...
}catch(SqlConstraintViolatedExceptionFactoryException e){
    // ...
}

Deliberately over-dramatized.

On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe <destructionator@gmail.com> wrote:

> Why aren't we using real words here? Real words are easier
> to remember and easier to type.

Should we use American or English spelling? Color verses Colour, for example?


-- 
Derek Parnell
Melbourne, Australia

On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:
> Should we use American or English spelling? Color verses Colour, for example?

I can go either way. I lean toward English spelling
though, simply because America is the exceptional
country (in the world and on the newsgroup too) in
this regard.

But, either option is better than "Clr" or "Col".

Le 06/03/2012 21:00, Timon Gehr a écrit :
> On 03/06/2012 07:13 PM, Alex Rønne Petersen wrote:
>> (Also, seriously, I think you're over-dramatizing the Java variable
>> naming thing; I rarely see names that are as bad as you claim...)
>>
>
> It is not only about single names, but also about how many times you
> have to spell them out in short intervals.
>
> try{
> SqlConstraintViolatedExceptionFactoryWrapper
> sqlConstraintViolatedExceptionFactoryWrapper = new
> SqlConstraintViolatedExceptionFactoryWrapper(new
> SqlConstraintViolatedExceptionFactory(...));
> SqlConstraintViolatedException sqlConstraintViolatedException =
> sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);
>
> throw sqlConstraintViolatedException;
> }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
> // ...
> }catch(SqlConstraintViolatedExceptionFactoryException e){
> // ...
> }
>
> Deliberately over-dramatized.

As I said, names comes in a context. Overly long names tell about the fact that the name isn't at the right place and things should be refactored, to provide a nice place to that named stuff.

auto helps too.

On 7 March 2012 10:30, deadalnix <deadalnix@gmail.com> wrote:
> Le 06/03/2012 21:00, Timon Gehr a écrit :
>
>> On 03/06/2012 07:13 PM, Alex Rønne Petersen wrote:
>>>
>>> (Also, seriously, I think you're over-dramatizing the Java variable naming thing; I rarely see names that are as bad as you claim...)
>>>
>>
>> It is not only about single names, but also about how many times you have to spell them out in short intervals.
>>
>> try{
>> SqlConstraintViolatedExceptionFactoryWrapper
>> sqlConstraintViolatedExceptionFactoryWrapper = new
>> SqlConstraintViolatedExceptionFactoryWrapper(new
>> SqlConstraintViolatedExceptionFactory(...));
>> SqlConstraintViolatedException sqlConstraintViolatedException =
>>
>> sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);
>>
>> throw sqlConstraintViolatedException;
>> }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
>> // ...
>> }catch(SqlConstraintViolatedExceptionFactoryException e){
>> // ...
>> }
>>
>> Deliberately over-dramatized.
>
>
> As I said, names comes in a context. Overly long names tell about the fact that the name isn't at the right place and things should be refactored, to provide a nice place to that named stuff.
>
> auto helps too.

I agree with whoever was talking about balance. This isn't a abbreviate vs not abbreviate discussion, its about when to abbreviate and when not to. Personally, I think Clock.currentTime() is fine, however Clock.currentTimeWithDST is not. There is also the argument of line length, less of an issue nowadays, but I try to stick with reasonable line-lengths, about 100 characters (was 80, but that ended up being too limiting for most purposes), If I have to use overly verbose names, then that eats into my "quota" for that line, especially annoying when I have string arguments that I don't want to have to split.

"dur" should be "duration" because its silly otherwise. Seconds should be either "secs" /or/ "seconds", but should be consistent, I'd say "secs" because it meshes well with the other, sub-second, times ("nsecs", "usecs" etc) and writing out "microseconds" is a bit verbose, especially when you're probably outputting them as "12 us" anyway...

--
James Miller

On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
> used to work!

Yes, and it was quickly changed to toISOExtString, because toISOExtendedString is painfully long. toISOExtString is bad enough, but you can't really make it any shorter without making the name uninformative.

> Nope, apparently, I meant "dur". Ridiculous.

A Duration needs to be constructed with a template, and duration!"hours"(13), duration!"seconds"(44), etc. is painfully long when used in expressions. So, it was shortened to dur. I don't know of any other abbreviation which would make sense.

I agree with H.S. Teoh in that abbreviations should be meaniful and consistent but that they _should_ be used where applicable. Code becomes painfully long otherwise - especially when chaining function calls and the like.

Symbol names should be descriptive while still being as short as they can reasonably be without losing meaning.

- Jonathan M Davis

On Tuesday, March 06, 2012 19:00:21 Andrej Mitrovic wrote:
> On 3/6/12, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> > It's coming from separate stopwatch module that got merged with std.datetime, so the blame is somewhat misplaced :)
> 
> I've argued about it with the current DateTime Czar, so it's not really missplaced. :)

Units which are sub-second are abbreviated. The others aren't. Making it secs would be more consistent with the sub-second names, but it would make it less consistent with the others. The only thing which would be completely consistent would be to abbreviate them all or to abbreviate none of them. Abbreviations get very ugly (and harder to remember IMO) with the larger units, and not abbreviating the smaller ones makes them ludicrously long. So, the compromise is to abbreviate the sub-second units and not the others. And I believe that std.datetime and core.time are very consistent with regards to how units are abbreviated.

Now, as for  TickDuration in specific, there's a good chance that it was the way that it is when it was created - in which case choosing seconds over secs for that wasn't me - but it's consistent with all of the rest of the time stuff regardless.

- Jonathan M Davis

On Tue, Mar 06, 2012 at 06:43:39PM -0500, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
> > writeln(time.toISOExtendedString()); // bzzt, wrong, but this
> > used to work!
> 
> Yes, and it was quickly changed to toISOExtString, because toISOExtendedString is painfully long. toISOExtString is bad enough, but you can't really make it any shorter without making the name uninformative.

You *could* shorten String to Str, but that would be inconsistent with everything else (e.g. toString), so that's a no-go.


> > Nope, apparently, I meant "dur". Ridiculous.
> 
> A Duration needs to be constructed with a template, and duration!"hours"(13), duration!"seconds"(44), etc. is painfully long when used in expressions. So, it was shortened to dur. I don't know of any other abbreviation which would make sense.
[...]

I'm on the fence about this one. It's true that duration!"seconds"(44) is uncomfortably long, but 'dur' also tends towards the side of meaningless, esp. if it occurs only once or twice in otherwise-unrelated code. I'm inclined to leave it as 'duration' since I can't think of any good abbreviations for it either.


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White

On 3/6/12 8:43 PM, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
>> used to work!
>
> Yes, and it was quickly changed to toISOExtString, because toISOExtendedString
> is painfully long. toISOExtString is bad enough, but you can't really make it
> any shorter without making the name uninformative.
>
>> Nope, apparently, I meant "dur". Ridiculous.
>
> A Duration needs to be constructed with a template, and duration!"hours"(13),
> duration!"seconds"(44), etc. is painfully long when used in expressions. So,
> it was shortened to dur. I don't know of any other abbreviation which would
> make sense.

Painfully long?

How much time does it take you to type 5 more chars? How much time does it take you to understand "dur" when you read it instead of "duration"?

>
> I agree with H.S. Teoh in that abbreviations should be meaniful and consistent
> but that they _should_ be used where applicable. Code becomes painfully long
> otherwise - especially when chaining function calls and the like.

Code becomes painfully long when you write lots of lines, not when you write long lines. Specially when you write lots of boilerplate lines.

> Symbol names should be descriptive while still being as short as they can
> reasonably be without losing meaning.
>
> - Jonathan M Davis

On Tue, Mar 6, 2012 at 4:53 PM, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Tue, Mar 06, 2012 at 06:43:39PM -0500, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
> > > writeln(time.toISOExtendedString()); // bzzt, wrong, but this
> > > used to work!
> >
> > Yes, and it was quickly changed to toISOExtString, because toISOExtendedString is painfully long. toISOExtString is bad enough, but you can't really make it any shorter without making the name uninformative.
>
> You *could* shorten String to Str, but that would be inconsistent with everything else (e.g. toString), so that's a no-go.
>
>
> > > Nope, apparently, I meant "dur". Ridiculous.
> >
> > A Duration needs to be constructed with a template, and duration!"hours"(13), duration!"seconds"(44), etc. is painfully long when used in expressions. So, it was shortened to dur. I don't know of any other abbreviation which would make sense.
> [...]
>
> I'm on the fence about this one. It's true that duration!"seconds"(44) is uncomfortably long, but 'dur' also tends towards the side of meaningless, esp. if it occurs only once or twice in otherwise-unrelated code. I'm inclined to leave it as 'duration' since I can't think of any good abbreviations for it either.
>
>
> T
>
> --
> A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White
>

I wasn't around for the creation of datetime but I'm curious why a boost
datetime-like duration construction shortcut approach to durations wasn't
used.  That is, you can write weeks(1), months(6), years(10), hours(17),
minutes(12), etc. (although there is now days(int) for some reason).