*Naming Conventions*

[Thorsten Kampe]

Okay,

I hear you saying 'not another naming conventions thread'. I've read
through Google and the 'naming conventions' threads were rather
*spelling conventions* threads.

I'm not interested in camelCase versus camel_case or anything
mentioned in 'PEP 8 -- Style Guide for Python Code'. What I'm looking
for is hints or ideas how to name your variables and especially how to
name functions, methods and classes.

I know this depends on what the function is doing. If I know what it
is doing I should be able to give them a desciptive name. But actually
I'm often not able. Especially when the task is quite similar to
another function or Class.

Recently I wrote this code and noticed that I was completely lost in
giving these objects names to describe and distinguish them:

for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

The 'tips' I got through some postings or articles on the net are: if
a function simply tests something and returns a boolean call it

def is_<whatever_yo u_are_testing_f or>():
pass

like 'is_even'.

Makes sense. The other thing I captured was to use something like

def get_values():

.... Makes sense, too, but aren't all functions getting something?

So if someone had a similar dilemma to mine and could tell me how he
dealt with that, I'd be grateful...
Thorsten

[Marc 'BlackJack' Rintsch]

In <MP************ ************@ne ws.individual.d e>, Thorsten Kampe wrote:

Recently I wrote this code and noticed that I was completely lost in
giving these objects names to describe and distinguish them:

for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

Wow, I know you don't want to talk about "spelling conventions" but here
you are mixing many of them. :-)

I don't know if it makes sense for your code, but maybe you can move the
``if`` condition into the class of `myAnswer` as overloaded ``in``
operator. Then this can be written as:

for valid_answer in valid_answers:
if valid_answer in my_answers:
my_options['style'] = valid_answer

The 'tips' I got through some postings or articles on the net are: if
a function simply tests something and returns a boolean call it

def is_<whatever_yo u_are_testing_f or>():
pass

The other typical boolean test prefix is 'has_'.

like 'is_even'.

Makes sense. The other thing I captured was to use something like

def get_values():

... Makes sense, too, but aren't all functions getting something?

So you may reduce this to just `values()`. On the other hand there is the
convention to name functions and methods as verbs that are "doing"
something.

Ciao,
Marc 'BlackJack' Rintsch

[Ninereeds]

On Jun 4, 5:03 am, Thorsten Kampe <thors...@thors tenkampe.dewrot e:

for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

First, for small loops with loop variables whose meaning is obvious
from context, the most readable name is usually something like 'i' or
'j'. It avoids unnecessary duplication and clutter. Of course, just as
physically turning your head to look in the rear view mirror is
necessary in a driving test but stupid for real driving, you are
likely to be penalised for this if you do it in an educational setting
or somewhere else where daft coding conventions are strictly enforced
(I once worked in a company that had library constants 'Zero' and
'One' defined because the coding conventions insisted on absolutely no
unnamed 'magic numbers' - spelling the numbers using letters
apparently didn't count).

Second, when naming a member, you should take into account that
references will already be specifying what the whole class describes.
That is, provide new information where possible, and avoid unnecessary
repetition.

Since Python is dynamically typed, it can be useful for names to
describe the datatype of the content at times (though not to the
Hungarian notation extreme that is common is C code, esp. for
Windows). And while most variable names are nouns, sometimes
adjectives are most appropriate - esp where the noun is already clear
from context.

Based on this, your code might become something like...

for i in validanswers:
if myAnswers.curre nt in myAnswers.valid List [i]:
MyOptions['style'] = i

'i'
Its obviously a validanswer since it is one of
the validanswers.

'myAnswers.curr ent'
I know its related to myAnswers, but the
adjective 'current' tells me more about this
specific member.

'myAnswers.vali dList'
'valid' on its own is useful extra information,
but suggests a flag field. validList is better
since it avoids that confusion.

Depending on what myAnswers.myans wer actually holds, it might
alternately be renamed something like myAnswers.uid or myAnswers.id (a
[unique] identifier code identifying the answer) or myAnswers.text
(the text of the answer).

It is also often useful to use a convention where a prefix identifies
whether a name is a (p)arameter, (l)ocal variable, or (m)ember
variable - no prefix for functions, usually. For example, a simple
setter method may logically use the same name for the parameter
specifying the value to write, the member variable to write to, and
(barring a prefix along the lines of 'Set') the method name.

[George Sakkis]

On Jun 3, 4:32 pm, Steve Howell <showel...@yaho o.comwrote:

I also still waste brain cycles on naming
dictionaries. Sometimes I name the dictionary after
the values it stores, sometimes after the keys it
uses, and sometimes after both.

I was in the same boat but now I've pretty much settled to the
convention `key2value`, e.g.:

name2func = {
'sum' : sum,
'avg' : lambda values: sum(values) / float(len(value s))
'product' : lambda values: reduce(operator .mul,values,1),
}

word2positions = {
'dog' : [3, 45, 79, 840],
'cat' : [56, 97, 810],
}

At some point I was torn between this and the plural form, i.e.
`keys2values`, but that's ambiguous in cases where each key or value
is a collection, such as the 'positions' above.

While we're at it, although it's not strictly a naming convention
issue I still waste brain cycles on where to put the import statements
that are used only once or twice in a module. Should
(1) all imports be at the global scope at the top of the module, or
(2) be imported in the function or method they are actually used ?

Reasons for (1)
---------------
- PEP-8 compatible.
- Easy to see all external dependencies in one place.

Reasons for (2)
---------------
- Point of import closer to point of use; easy to notice if a given
import is not used any more after refactoring.
- Less name pollution.
- Faster name lookup in locals (might make a difference for tight
loops).

I usually go for (1), at least until the number of global imports in
the top remains in single digits. After some point though I often
localize the standard library imports that are used only once or twice
(the third-party and local application imports are almost always
global). Any others that are not strictly PEP-8 compliant on this ?

George

[Dan Bishop]

On Jun 3, 11:03 pm, Thorsten Kampe <thors...@thors tenkampe.dewrot e:

Okay,

I hear you saying 'not another naming conventions thread'. I've read
through Google and the 'naming conventions' threads were rather
*spelling conventions* threads.

I'm not interested in camelCase versus camel_case or anything
mentioned in 'PEP 8 -- Style Guide for Python Code'. What I'm looking
for is hints or ideas how to name your variables and especially how to
name functions, methods and classes.

In my code:

* The most common form of a function/method name is verb_noun. Other
common patterns are adjective_noun, noun_to_noun or noun2noun (for
conversions), and noun_of_noun.

* Classes nearly always have AdjectiveNoun names.

* Loop indices often have single-letter names (typically i/j/k or x/
y), or names that are the singular form of the list name (e.g., "for
ballot in self._ballots") . For iterating over files, I use "line".

[Michael Hoffman]

Thorsten Kampe wrote:

for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

I usually try to avoid using "my" because I find it obscures a better
understanding of what is really going

--
Michael Hoffman

[Michael Hoffman]

Michael Hoffman wrote:

Thorsten Kampe wrote:

>for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

I usually try to avoid using "my" because I find it obscures a better
understanding of what is really going

....on.

Whoops, sorry about missing the last word of that message.
--
Michael Hoffman

[Marc 'BlackJack' Rintsch]

In <11************ **********@q75g 2000hsh.googleg roups.com>, George Sakkis
wrote:

While we're at it, although it's not strictly a naming convention
issue I still waste brain cycles on where to put the import statements
that are used only once or twice in a module. Should
(1) all imports be at the global scope at the top of the module, or
(2) be imported in the function or method they are actually used ?

[…]

Reasons for (2)
---------------
- Point of import closer to point of use; easy to notice if a given
import is not used any more after refactoring.

`pylint` reports unused imported names. I don't follow PEP8 only if it's
not possible otherwise. But cyclic imports are bad anyway. :-)

And if the import is *really* expensive and only needed in some special
circumstances.

Ciao,
Marc 'BlackJack' Rintsch

[bruno.desthuilliers]

On Jun 4, 12:20 am, Ninereeds <stephenhorne.. [e-mail]:

On Jun 4, 5:03 am, Thorsten Kampe <thors...@thors tenkampe.dewrot e:

for validanswer in validanswers:
if myAnswers.myans wer in myAnswers.valid Answers[validanswer]:
MyOptions['style'] = validanswer

First, for small loops with loop variables whose meaning is obvious
from context, the most readable name is usually something like 'i' or
'j'.

'i' and 'j' are the canonical names for for loops indices in languages
that don't support proper iteration over a sequence. Using them for
the iteration variable of a Python for loop (which is really a
'foreach' loop) would be at best confusing.
(snip)

Based on this, your code might become something like...

for i in validanswers:
if myAnswers.curre nt in myAnswers.valid List [i]:
MyOptions['style'] = i

And this is *exactly* what one should not do in Python. If you want a
generic name here, use 'item' instead.

It is also often useful to use a convention where a prefix identifies
whether a name is a (p)arameter, (l)ocal variable, or (m)ember

You don't have to use any kind of prefix for attributes ('member' is
not a Python idiom - remember that in Python, a method is also an
attribute...) since the use of 'self' is mandatoy.

And you usually don't need to distinguish 'local' from 'parameters',
since
1/ parameters names *are* local
2/ pythonic methods and functions tends to be short, so you usually
know which names are params.
FWIW, prefixing names this way is something I've almost never seen in
Python code.

variable - no prefix for functions, usually. For example, a simple
setter method

Python has a pretty good support for computed attributes (look for
'property'), so you don't need explicit getters/setters.

[Wildemar Wildenburger]

br************* ****@gmail.com wrote:

On Jun 4, 12:20 am, Ninereeds <stephenhorne.. [e-mail]:

>First, for small loops with loop variables whose meaning is obvious
from context, the most readable name is usually something like 'i' or
'j'.

'i' and 'j' are the canonical names for for loops indices in languages
that don't support proper iteration over a sequence. Using them for
the iteration variable of a Python for loop (which is really a
'foreach' loop) would be at best confusing.

While that is true, I guess it is commonplace to use i, j, k and n
(maybe others) in constructs like

for i in range(len(data) ):
do_stuff(data[i])

Or should the good python hacker do that differently? Hope not ;).

/W