Well, the underscored names might be easier to read since the words are spaced apart. They might be easier to type as well, if you set a hotkey for _. With camelcase you either have autocomplete to help you or you have to use Shift all the time (you need shift for _ as well unless you set a hotkey for it).

Jonathan M Davis wrote:
> 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

Even worse -- 'en' _is_ a word! (From typography, with 'en' and 'em'). It could mean a narrow tab, in contrast to an emTab, which would be a wide tab...

It's unfortunate that the dominant language for programming is the one with by far the worst spelling.

> 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.
Agree on every bit!
Silly me, i was thinking you are one of those (or the one) that enforce camelCase!

On 22.01.2011 01:36, Sean Kelly wrote:
> 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.

No problem:

Some_type
some_variable

I haven't actually used this style personally.  I've just noticed that it's the style used throughout Stroustrup's latest book (Programming). Seems like the obvious next step for the underscore style of naming.

On Fri, 21 Jan 2011 18:16:20 -0600, 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.
> 
> Andrei

Hehe. This the one only case I'm happy we can't turn back the time ;) For me camelCase is *much* more beautiful  than underscores. When reading STL code my eyes coupled with brain  have  difficulties with instant distinction where the name exactly  starts and ends (thanks to intention of simulating spaces).

PS. One worders are the best, of course.

Cheers
Piotrek

On 22/01/11 10:55, bearophile wrote:
>> I think variable names in camelcase are less noisy.
>
> Sorry, I meant:
>> I think variable names in camelcase are more noisy.
>
> Bye,
> bearophile


I think youAre probablyRight (that camelCase is moreNoisy) but unfortunately yourArgument foundered beCause of a typoMistake.

:-) Justin

On 01/22/2011 02:16 AM, Andrei Alexandrescu wrote:
> 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
>

My problem with underscore-delimited identifiers is that they can get really hard on eyes:

int my_temp_var = some_object_instance.some_field.some_other_field;

The dots are completely lost. Also, when identifiers are getting long (and in large libraries they tend to) the underscores become to look pretty annoying. I have worked with many conventions and camelCase remains my favorite for now.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.804.1295659471.4748.digitalmars-d@puremagic.com...
>
> 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.
>

I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like "typing" and more like "finger acobatics."

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.

Sorry for being unclear. My comment was only in the context of is_. I like separating "is" with an underscore. Probably because "is" is not part of the name. It operates at a different linguistic level.

> 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).

Same here: always camelcase, except in our C libraries. Now I like underscore more than before. :)

> 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.

I am aware of that. Then half seriously, let's change the standard to use underscore after "is". Also when parts of a camelcased name are too loosely related.

For example, when NodeReader is an interface and when we already have a LovelyDb, we may have a class named LovelyDb_NodeReader.

Ali

> I'm the same way. Plus, I find it really awkward to constantly type a bunch
> of underscores. It feels less like "typing" and more like "finger
> acobatics."

It is worse for camelCase, at least you can bind "_" to another key.
Only one thing i like about camelCase is that, it takes less space.