January 21, 2011
On Friday, January 21, 2011 13:46:11 Tomek Sowiński wrote:
> 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?

As far as Phobos goes, constants are named the same way that any other variable is. I don't think that there are any special naming conventions based on variable type or constness or whatnot. It's all based on the type of symbol. Typically, everything is camelcase, user-defined types start with a capital letter, and everything else starts with a lowercase letter.

The most typical constants are enums, but there are cases where you can't do that, because CTFE isn't advanced enough yet (like with you configuration tree structure), in which case immutable is used along with static constructors. Ideally though, they'd pretty much always be generated with CTFE and be enums.

Generally-speaking, when referring to constants, people are referring to variables with a global lifetime which are set to an initial value and never (and cannot ever) change once set.

- Jonathan M Davis
January 21, 2011
On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:
> Andrei Alexandrescu wrote:
>  > iswhite
> 
> I like separating is with an underscore, like most coding styles do:
> 
>    is_whitespace
> 
> Warm and fuzzy... :)

Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions.

- Jonathan M Davis
January 21, 2011
Jonathan M Davis:

> Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores.

You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy.

Bye,
bearophile
January 21, 2011
On 01/22/2011 12:17 AM, bearophile wrote:
> You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy.

I have used underscores for a long time, then had to switch to camelcase for conformance with an enforced coding style. Annoyed for a while. Then, I realised that camelcase may be better because it is visually clearer in complicated expressions; I mean '_' is too "shy", it doesn't obviously enough tie together parts of a single identifier.
Even '-' (heavily used in languages that allow it) is too "shy".
I also don't like '_' at start/end of ids for similar reasons.
	xyz.foo_._bar (param);
(But it's only me...)

Denis
_________________
vita es estrany
spir.wikidot.com


January 21, 2011
> I think variable names in camelcase are less noisy.

Sorry, I meant:
> I think variable names in camelcase are more noisy.

Bye,
bearophile
January 21, 2011
On 01/21/2011 10:46 PM, Tomek Sowiński wrote:
> 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?

Very personal def: I give constant & variable about the same meaning as in math: something predefined, or conversely undefined, at design time (which implies in a compiled language also at compile-time).
	f : x --> k.x
k is a constant, x a variable. Same below:
	factor3 = 3;
	int triple (int x) {return factor3 * x;}
Thus, I consider "enum" and "static" (in some of its numerous senses) as constant qualifiers.

Denis
_________________
vita es estrany
spir.wikidot.com

January 22, 2011
On 1/21/11 4:49 PM, Jonathan M Davis wrote:
> On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:
>> Andrei Alexandrescu wrote:
>>   >  iswhite
>>
>> I like separating is with an underscore, like most coding styles do:
>>
>>     is_whitespace
>>
>> Warm and fuzzy... :)
>
> Most? I've never dealt with a coding style that had underscores. It's generally
> camelcase, though I get the impression that using underscores in C code is more
> common (I've mostly used C++ and Java). Regardless however, Phobos' coding style
> uses camelcase, not underscores. And this whole thread was started to try and
> find better names for functions which need new names, because they don't
> currently follow Phobos' naming conventions.

Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout.

Andrei

January 22, 2011
Andrei Alexandrescu Wrote:
> 
> Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores.

I like the look of the STL convention, but overall prefer that Camel case distinguishes between types and values.  It completely eliminates the need for a "_type" suffix in STL-style typedefs, for one.
January 22, 2011
On Friday, January 21, 2011 15:17:00 bearophile wrote:
> Jonathan M Davis:
> > Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores.
> 
> You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy.

Probably because Walter and/or other folks working on it early on preferred camelcase. I'm welling to bet that a fair number of the current Phobos devs are the same (though apparently, Andrei isn't, given one of his posts in this thread). I expect that Phobos uses camelcase simply because that's what enough of the Phobos developers (particularly early developers) were used to.

Personally, camelcase vs underscores isn't even something that I normally think about. I just always use camelcase. On _rare_ occasion, I might use underscores because it seems to fit a particular situation, but that's _really_ rare. The only time that I normally stick underscores in variable names is to indicate private member variables. But I find using underscores in names to generally be ugly and noisy. I expect that a lot of that just comes down to what you're used to though.

- Jonathan M Davis
January 22, 2011
On 01/22/2011 01:16 AM, Andrei Alexandrescu wrote:
> Ever since I worked with STL, I fell in love with
> names_with_underscores. I can't explain it, but my feeling is that code
> using that convention is calm and levelheaded. Camel case forces me to
> think of one-word names because at the second word some beauty is
> already lost; never felt the same with the underscores. If I could go
> back in time I'd propose that convention throughout.

Nice, & surprising! I do not share your feeling (not at all), but I like very much the way you express it; and the weirdness to associate such a feeling with something_like_underscored_ids.

> Andrei

Denis
_________________
vita es estrany
spir.wikidot.com