On Tuesday, June 3, 2014 6:27:25 AM UTC+5:30, Ben Finney wrote:
Steven D'Aprano writes:
On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
I invoked the wrong bug.py :/ , works fine now (this happens to me
when im a bit tired sometimes...).
Clarity in naming is an excellent thing […] Programs should be named
by what they do […] or when that isn't practical, at least give them a
unique and memorable name […].
It's worth noting, along with this useful admonition, that naming things
well is one of the most difficult things to do.
It is especially difficult in computer software, while also being rather
more important than the typical problem of naming, because of the
simultaneous constraints that the names within computer software should
be:
* Memorable and evocative of the meaning to humans, who have a limited
capacity for remembering large sets of different names exactly, but a
high tolerance (even fondness) for multiple-meaning and ambiguous
words.
So, choosing unique names is difficult, and the set of memorable names
is severely limited.
* Starkly unique and exact every time for the computer's use, without
regard to meaning, and any name is just as memorable to a computer as
any other.
So, choosing unique meaningful names is crucially important in working
with computer software.
That combination – difficult but important to do well – is a perennial
bugbear for programmers.
Add to that the restriction to limited character sets such as ASCII
– a restriction that has only historical relevance
Somewhat more seriously there is the complement to Ben/Steven's remarks:
Good software systems reduce the naming-demand.
Egs.
1. Computationally/algorithmically, these 2 are equivalent:
a.
desc = sqrt(b*b - 4*a*c)
b.
left = b*b
t1 = 4*a
right = t1*c
desc = left - right
sqrt_desc = sqrt(desc)
However the naming load of the b is 5 times a – one of the main
benefits of a high level language vs assembly
In the same vein…
2. λ-expressions reduce the need to name functions.
3. Point-free style – or more on-topic Tacit Programming –
reduces the need for function arguments
http://en.wikipedia.org/wiki/Tacit_programming
4. Structured programming removes the need to name control points with labels
5. And problems like this one can be reduced by using the interpreter
more and named program files less. Of course even if you can check
in the interpreter, to communicate with others/file a bug you may need to
name a file.
--
https://mail.python.org/mailman/listinfo/python-list
