[OT]Another n00b: Removing the space in "print 'text', var"
Bruno Desthuilliers
bdesth.quelquechose at free.quelquepart.fr
Mon Feb 13 18:36:47 EST 2006
Rick Zantow a écrit :
> bruno at modulix <onurb at xiludom.gro> wrote in
> news:43f05016$0$1408$626a54ce at news.free.fr:
>
>
>>HappyHippy wrote:
>>
(snip)
>>>eg.
>>>strName = 'World'
>>>print 'Hello', strName, ', how are you today?'
>>
>>Already got an anwser, now just a coding-style suggestion: hungarian
>>notation is *evil*. And even *more* evil with a dynamically-typed
>>language.
>>
>
> <OT>
> Although I agree with you in part (about the horror that is often called
> "Hungarian notation"),
(snip)
>
> However, that is not how Hungarian notation was meant to be used.
> Instead, the prefix was to indicate the function of the variable, not
> its datatype.
I know that. But:
1/ 99% of the developpers using (ms-perverted) hungarian notation ignore
this fact
2/ the name itself should be a clear enough indication of the [role,
function, intended use] of the variable (<pedantic>well, of the object
bound to that name in fact</pedantic>)
3/ see below...
4/ see below...
> Thus, ctrXXX would be a counter (according to some
> hypothetical coding standard).
or a controller, according to some other hypothetical coding standard...
3/ prefixing (instead of suffixing) breaks readability.
compare :
- hit_counter
- hit_controller
- ctrHit
Which one do you find the most readable ? Clearly, prefixing (vs
suffixing) puts things in the wrong order. And clearly, a three letters
abbrev gives less information than a word.
(snip)
> In the HappyHippy example, the 'str' prefix does coincide with Python's
> indicator of a string class, as it happens.
as it happens... cf /1
> It is not clear that it need
> be more than coincidence, though.
Which, given /1, is enough to confuse the situation. Ho, my, does this
prefix means that it's supposed to be a string, or is it mere
coïncidence ? And if so, what is this 'str' prefix supposed to mean ?
So much for readability...
> A string of bytes need not be of class
> str, and text need not be contained in a Python str, but the 'str'
> prefix could easily be attached to anything that indicated strung-
> together data under some coding standard or another.
>
> Specifically, it
> wouldn't bother me greatly to discover that strXXX contained a normal
> Python string at some point and a Unicode string at another -- the
> function of strXXX would be the same in either case.
4/ Well, I'm afraid that 'strung-together data' is more a type
indication than a 'function' indication. And what should I say about
byte string or Unicode...
> Dealing with the contents of strXXX might be a problem, of course, but
> that would also be true whenever the datatype of its contents could
> vary, regardless of its name. In a dynamic language, that variance could
> easily happen, which appears to be the basis for your "even *more*
> evil" comment.
Of course.
> Appending a pseudotype prefix to an object's name doesn't
> fix the situation, but it doesn't really make it worse.
Yes it does. How do you like:
strAnswer += 42
> A prefix of
> 'str' should be enough to warn a maintainer not to assume the field is
> an accumulator or a function name,
A maintainer should not assume much IMHO. Heck, a function *name* is a
string, isn't it ? And BTW, if, following some weird naming convention,
the 'str' prefix was used to indicate 'strung-together-data', it could
as well be used for any sequence(strung-together-data) - in which case
it could be used for an accumulator !-)
> and maybe a little more than that,
> but in any event, in any language, the only sure way to know how an
> object is being used is to examine its context in the source.
So what's the use of prefixing it's name with distracting information ?
(snip)
> Now it could be that I'm misinterpreting your objection to Hungarian
> notation.
I'm afraid my objections to HN are nothing new.
> If so, I'd be interested in hearing what it is.
Then you're done. To summarize:
- it's useless
- it's distracting
- it can be misleading
- it doesn't help readability
According to Python's zen:
- Beautiful is better than ugly.
- Readability counts.
- In the face of ambiguity, refuse the temptation to guess.
> Although I
> don't imagine any of this is actually on topic in the Python group.
oops ! Sorry y'all
> </OT>
More information about the Python-list
mailing list