Yet Another Case Question

[Björn Lindberg]

Alex Martelli <aleax at aleax.it> writes:

> IF Python was case-insensitive, you might freely PRETEND the
> convention was universally applied, spelling that particular
> constant as math.PI in your code for example.  As things stand
> (and will keep standing, alas), you cannot even pretend: you
> must inherently acknowledge every time you use something as
> fundamental as standard module math that the convention is in
> fact broken all over the place.  Quite a way from "enforcing"!!! 

I would like to add one viewpoint here. I think you are painting a
little too bright a picture here when you say that names of different
capitalisation schemes could be used interchangeably. The two most
common capitalisation schemes are CamelCase and no_case. Personally, I
have a strong dislike for camel case which I find distrubing and
difficult to read. Therefore, I use underscores. Normally I don't even
capitalise class names, although that depends on which language I'm
working in. Anyway, my funtion names will look like
generate_binary_tree, and get_token, and such. A person favouring camel
case could not apply it to my variable names. The best he/she could
do, is Generate_Binary_Tree, and get_Token, which is probably not what
he wants. It works equally bad the other way around. Any longer camel
case name will look completely incomprehensible in only small
letters. A person like me, who favours the underscore notation, would
have to make do with generatebinarytree, and gettoken. In practice, I
would probably be forced to use camel case anyway, just to be able to
write the names correctly.

So, your freedom of choice in notation is in practice really only
valid for short names. For longer names, there will be no
improvement. I predict then that the smaller names would be written in
a style dictated by how the larger names are already written, for some
module or a project utilising several modules.


Björn