Module naming conventions

[Steven Schveighoffer]

"Bill Baxter" wrote
>> *) Easy-to-remember rule ("just use lowercase") prevents naming errors
>> slipping through the cracks on case-agnostic Windows.
>
> I've already said that I don't understand why this is a big deal , but it 
> was the the reason brought up by Walter.  (And my paraphrasing above is 
> not exactly what he said, but the only way I could make any kind of 
> logical sense out of it.)

Here is why it's a deal (maybe not big, perhaps melon-sized):

import tango.io.XmlFile
import tango.io.XMLFile

(note these are not real modules)

I intuitively use the second version, because it looks weird to me when you 
change the case of an acronym.  But some people may intuitively use the 
first.

So let's say for argument's sake that XmlFile.d is the real version.  If I'm 
developing my application on windows, and my pre-programmed fingers type 
'XMLFile', it compiles, without me realizing that the case is wrong.  When I 
try porting to Linux, I now get an error because XMLFile.d doesn't exist, 
it's XmlFile.d.

See, the problem with CamelCase is that it is sometimes subjective as to 
what part of the name should be capitalized.  This in itself isn't a huge 
problem except that on case-insensitive file systems, it is possible for the 
program to compile even though it shouldn't.

If all module names are lower case, then this doesn't happen.  I know that I 
have to lower the case of everything, even acronyms.  There is no 
subjectivity.

Is this a big deal?  Not really.  Back to my example, if I'm porting to 
Linux, I see the problem from the compiler, then I fix my files (probably 
with a search/replace script), and I'm done.  In the code, even on Windows, 
I'm not able to compile if I use the *class name* XMLFile, so the only part 
that doesn't work is the import.

So there's reason for wanting lower case, and reason for wanting CamelCase. 
I don't think either is right or wrong, or that either reasoning far 
outweighs the other.

-Steve