*Naming Conventions*

[Ninereeds]

Google Groups appears to have thrown away my original reply, so sorry
if this appears twice...

On Jun 4, 9:51 pm, "bruno.desthuilli... at gmail.com"
<bruno.desthuilli... at gmail.com> wrote:

> '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.

Without wanting to start a religious war, I disagree.

In practice, I believe most programmers associate those short names
with pretty much any loop

variable, irrespective of data type, based primarily on the simple
fact that it's looping

over a set of values whose meaning is obvious from context. That
declaration is made after

decades of working with other peoples code as well as my own.

Don't believe me? Take a look at some code that uses C++ iterators,
for example, or some C

code that uses pointers as iterators, or some Ada code that loops over
an enumerated type,

etc etc. It won't find you long to realise that 'i' and 'j' are very
common names for those

too.

I've seen 'i' used in "iterations" over lists in Scheme, OCaml and
Haskell, whether done

using tail recursion or list comprehensions or whatever. 'x' is more
common, as with 'x:xs'

patterns used to pick the head 'x' from a list in OCaml or Haskell,
but then 'x' looks

scarily like an ordinate we can't have that ;-)

Anyway, why should 'indexes' always be numeric...

> >   for i in validanswers:
> >     if myAnswers.current in myAnswers.validList [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.

In this code, 'i' is appears to be just an answer identifier. It is
used to identify for

which answer in the validList you are looking for. It may well even be
a numeric index (or

some other kind of key), from what we can see in the example.

"item" says nothing that "i" does not. If nothing else, you could
always say that 'i' is

short for 'item' or 'id' or whatever.

> since the use of 'self' is mandatoy.

That is true, making 'm' prefixes pointless in Python, but that's what
comes from working

with many different language. You don't always keep them neatly
compartmentalised in your

head. Habits can be very strong, and there is not always any strong
reason to try to break

them. Which is why you will still occasionally see 'm' prefixes in
Python code.

Actually, in *my* Python code you're still more likely to see
'f' (standing for field)

prefixes - a convention I adopted in C++ at a time when I thought 'm'
better suited macros,

and when I'd never yet seen the 'm' for member prefix since most C++
code I'd seen still used

the Hungarian conventions. It's a bad habit that I still haven't fully
broken.

> 1/ parameters names *are* local

As they are in C and C++. Not just in terms of scoping, but in terms
of being local variables

too...

  int factorial (int p)
  {
    int l = 1;
    while (p > 1)  {  l *= p;  p--;  }
    return l;
  }

  def factorial (p) :
    l = 1
    while p > 1 : l *= p; p -= 1
    return l

Updating parameters when you could just as easily update locals is of
course bad style in

either language - and some would say that any updating of parameters
is bad style - but the

point is that C and Python do the same thing.

This example does illustrate another useful fact about the 'l' and 'p'
prefixes - there are

times when the prefix is all you need to specify the whole name, since
there really is

nothing else that can be usefully be said.

> 2/ pythonic methods and functions tends to be short, so you usually
> know which names are params.

Well written functions and methods in any language tend to be short,
but even so, there are

times when a convention that distinguishes the two kinds of names
without needing to think up

distinct names is convenient. I wasn't suggesting that this convention
should be universally

adopted in Python or that it was relevant to Thorstens example even -
but it is common in

many languages (not just C++), and it does sometimes help resolve the

how-can-I-give-these-meaningfully-different-names issue.

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

I may not use Python as my first and only language, but I have been
using it since version

1.4 and I am perfectly aware of properties in Python, as I am in other
languages. I am aware,

for example, that they are relatively new additions to the language,
that they are not used

in a lot of code, and that you still need named getter and setter
functions to redirect the

property access to even if these names are only referred to in the
property definition.

All of which is mostly besides the point. More and more programmers
are multilingual these

days, and scripting languages such as Python are more likely second
languages than first.

Having a hard rule that conventions from one language should never
leak into another, and

that Python code should be somehow 'pure', is pointless, particularly
when those conventions

are common in many languages. Thorsten was having difficulty in
finding distinct names, and I

described a common naming convention that is often useful for this. I
don't think I was wrong

to do that.