Language mavens: Is there a programming with "if then else ENDIF" syntax?

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Wed Nov 18 20:13:22 EST 2009


On Wed, 18 Nov 2009 15:58:24 -0800, Steve Howell wrote:

> On Nov 18, 2:22 pm, Steven D'Aprano
> <ste... at REMOVE.THIS.cybersource.com.au> wrote:
>> On Wed, 18 Nov 2009 02:06:49 -0800, Steve Howell wrote:
>> > P.S. The underscores before the method names might look a little
>> > funny for inner methods, but it's the nature of the code..._dict and
>> > _list would lead to confusion with builtins, if not actual conflict.
>>
>> Then name them something sensible that tells what they do!
>>
>> The convention (which you break at your peril) is that functions are
>> verbs, and classes are nouns. Even "handle_dict" is better than _dict
>> -- the latter looks like you're calling a private mapping type.
>>
>>
> Do you verbify functions with no side effects?  Do you prefer
> calculate_cosine(angle) to cosine(angle)?


Neither, I prefer cos(angle).

Mathematical functions are a special case. They have been around since 
long before computers, and there is a whole different tradition for them. 
(The tradition is that most functions are named after Euler, or the first 
person to discover them after Euler.)

But you're right, the convention of using verbs for functions isn't as 
strong as the convention of using nouns for classes and types. Functions 
that return some property of a noun are often named after the property:

len(x) rather than get_len(x)
sqrt(x) rather than calculate_sqrt(x)

and similar.

Likewise, conversion functions are often named after the return result:

int(x) returns an int
str(x) returns a str

[pedant]
these are actually types, not functions, in Python
[/pedant]


But I'm not sure what naming convention you used. It seems fairly 
arbitrary to me, but whatever it is, it clashes with built-ins, which is 
a good sign that you need a different set of names. Since naming the 
functions with leading underscores also clashes with the convention that 
such functions are private, that's a further sign that you should use a 
different naming convention. At the point that you are apologizing for 
the convention you use, maybe you should rethink it.

But of course it's your code, and you're free to use whatever convention 
you like.



-- 
Steven



More information about the Python-list mailing list