On 01/21/2011 09:44 AM, Jonathan M Davis wrote:
> Well, entab, I'd argue_does_  follow the naming convention, because entab would
> be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so
> I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but
> I'd argue that entab is a single word and fine as it is.

I fully agree with you on the linguistic side: "entab" is a single-word term, just like eg "input" (no-one would suggest "inPut" ;-). But practically, the decomposition "enTab" helps understanding this identifier by nicely highlighting "tab", don't you think?
This is even more relevant for foreigners, who have here to guess: (1) that "entab" is not a 'normal' english single-word term they would just not know (2) as you say, that en- is a verb-forming prefix in english one can more or less freely use. Non-trivial.

Denis
_________________
vita es estrany
spir.wikidot.com

On 01/21/2011 10:14 AM, Jacob Carlborg wrote:
> ljustify -> leftJustify /justifyLeft
> rjustify -> rightJustify/justifyRight
> stripl -> stripLeft
> stripr -> striptRight

Consistency. Eg: all qualifiers come first (like in english).

Denis
_________________
vita es estrany
spir.wikidot.com

On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:
> These should be expanded a bit and camelCased:
>
>    LS:        lineSep, lineSeparator
>    PS:        paragraphSep, paragraphSeparator

Isn't there a rule that constants all fully uppercase?

Denis
_________________
vita es estrany
spir.wikidot.com

> ljustify ->  leftJustify
> rjustify ->  rightJustify
> stripl ->  leftStrip
> stripr ->  rightStrip

I suggest it should be rather justifyLeft/Right and stripLeft/Right. It's easier to read and it works better with code completion.

On Friday, January 21, 2011 06:04:53 spir wrote:
> On 01/21/2011 09:44 AM, Jonathan M Davis wrote:
> > Well, entab, I'd argue_does_  follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is.
> 
> I fully agree with you on the linguistic side: "entab" is a single-word
> term, just like eg "input" (no-one would suggest "inPut" ;-). But
> practically, the decomposition "enTab" helps understanding this
> identifier by nicely highlighting "tab", don't you think?
> This is even more relevant for foreigners, who have here to guess: (1)
> that "entab" is not a 'normal' english single-word term they would just
> not know (2) as you say, that en- is a verb-forming prefix in english
> one can more or less freely use. Non-trivial.

I'm afraid that I don't agree at all. enTab is hideous and arguably confusing precisely because en is _not_ a word. I'd start trying to figure out what en was short for if I saw an enTab function. entab is _far_ clearer. Would you make a function named enClose? I should hope not. Granted, enclose is actually a word that you'll find in a dictionary, but en is a normal prefix in English, and trying to treat it as a word or abbrevation in function names would just be confusing.

- Jonathan M Davis

On Friday, January 21, 2011 06:20:30 spir wrote:
> On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:
> > These should be expanded a bit and camelCased:
> >    LS:        lineSep, lineSeparator
> >    PS:        paragraphSep, paragraphSeparator
> 
> Isn't there a rule that constants all fully uppercase?

That would be typical in C++ or Java, but that's not the case in D. Phobos certainly doesn't work that way in general, and Andrei doesn't want it to. The reasoning is that constants are so common in D (likely due to CTFE) that you'd have variables all over the place which were in all caps, and it would get really annoying. So, no. There is no rule in D that constants should be fully uppercase.

- Jonathan M Davis

On Friday, January 21, 2011 06:16:16 spir wrote:
> On 01/21/2011 10:14 AM, Jacob Carlborg wrote:
> > ljustify -> leftJustify /justifyLeft
> > rjustify -> rightJustify/justifyRight
> > stripl -> stripLeft
> > stripr -> striptRight
> 
> Consistency. Eg: all qualifiers come first (like in english).

Actually, it's a bit funny in this case. You're stripping the left of the string or the right of the string, so stripLeft and stripRight make  a lot more sense than leftStrip and rightStrip (actually, those would be pretty horrible IMO). However, when talking about justifying text, you typically talk about it being left-justified or right-justified (or centered). So, it's more natural to have leftJustify and rightJustify. Now, it might technically be more correct to talk about justifying it to the right or left, but no one really talks that way. I believe that left justify and right justify are typically used as if they were composite verbs rather than talking about justifying text to the right or left.

So, it's going to make more sense to most people to have stripLeft, stripRight, leftJustify, and rightJustify rather than trying to put right and left on the same side for both strip and justify.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday, January 21, 2011 06:20:30 spir wrote:
>> On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:
>>> These should be expanded a bit and camelCased:
>>>    LS:        lineSep, lineSeparator
>>>    PS:        paragraphSep, paragraphSeparator
>> Isn't there a rule that constants all fully uppercase?
>
> That would be typical in C++

That is typical only for macros in C++.

I know that some shops use all capitals for constants, but not the standard library nor any of the places that I worked at. :)

Ali

Andrei Alexandrescu wrote:

> iswhite

I like separating is with an underscore, like most coding styles do:

  is_whitespace

Warm and fuzzy... :)

Ali

Jonathan M Davis napisał:

> > > These should be expanded a bit and camelCased:
> > >    LS:        lineSep, lineSeparator
> > >    PS:        paragraphSep, paragraphSeparator
> > 
> > Isn't there a rule that constants all fully uppercase?
> 
> That would be typical in C++ or Java, but that's not the case in D. Phobos certainly doesn't work that way in general, and Andrei doesn't want it to. The reasoning is that constants are so common in D (likely due to CTFE) that you'd have variables all over the place which were in all caps, and it would get really annoying.

Right on.

> So, no. There is no rule in D that constants should be fully uppercase.

So if not uppercase, what is the convention for constants then? And, to hair-split more, what is a constant to begin with? Would e.g. a big immutable configuration tree structure fall into that bucket? Or a logger object?

-- 
Tomek