Rick Zantow a écrit : > bruno at modulix <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > >>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> -- http://mail.python.org/mailman/listinfo/python-list
