CamelCase versus wide_names (Prothon)

[Colin J. Williams]

Hans Nowak wrote:
> Mark Hahn wrote:
> 
>> We have agreed in Prothon that unlike Python we are going to be 100%
>> consistant in our var and method naming.  We will not have run-together
>> words like iteritems, we are going to always have seperated words like
>> has_key.
>>
>> Now we are in the midst of a discussion of camelCase versus 
>> wide_names.  So
>> far our arguments are:
>>
>> 1) CamelCase is more elegant, modern, more readable, and more 
>> efficient in
>> character usage.
>>
>> 2) Wide_names is cleaner, more readable, compatible with C, which is the
>> standard module language for Python and Prothon.  Wide_names is also the
>> Python standard.
>>
>> Of course in the Python world you alread have wide_names as your 
>> standard,
>> but could you for the moment pretend you were picking your standard from
>> scratch (as we are doing in the Prothon world) and give your vote for 
>> which
>> you'd prefer?
> 
> 
> That would be wide_names.  CamelCase would be tolerable.  In my own 
> code, I use a mixture: CamelCase for class names, wide_names for 
> everything else (inspired by older Python code).  Not mixedCase, mind 
> you; IMHO, that's an atrocity.  If you're going to use caps in names, 
> then at least the first letter should be capitalized.  Putting the 
> capitals somewhere in the middle but not in the front seems very 
> unnatural to me.
> 
My preferences are:

module names:  lower case.    to cope with case insensitive file systems
class names:   PascalCase.    this is comonly used
other names:   camelCase.     one has to choose something and this
                               avoids underscores
indent depth:   2             two is enough to give a visual break and
                               this reduces line wrape with multiple
                               indents

On the other hand as another contributor said, when amending existing 
code, it make sense to try to stick with whatever was done before.

Colin W.