Does it make sense to use Hungarian notation prefixes in interpreted languages? [closed]?

The reason Hungarian notation conveying type ("systems Hungarian") is frowned upon in Python is simple. It's misleading. A variable might be called iPhones (the integer number of phones, maybe :-) but because it's Python, there's nothing at all to keep you from putting something other than an integer into it!

And maybe you will find you need to do that for some reason. And then all the code that uses it is very misleading to someone trying to understand it, unless of course you globally change the name of the variable. This notation was intended to help you keep track of variable types in statically-typed languages and was arguably useful for a time.

But it's obsolete now, even for statically typed languages, given the availability of IDEs that do the job in a much better way.

It depends on which of the two versions you refer to: If you want to use the "real", original Hungarian notation AKA Applications Hungarian notation, denoting the logical variable type resp. Its purpose, feel free to do so. OTOH, the "misunderstood" version AKA Systems Hungarian notation, denotng just the physical variable type is frowned upon and should not be used.

– Throwback1986 2 days ago 2 I would suggest you read the original intent of Hungarian notation.To summarize, the intent was to convey use or semantics, rather than data storage type. I find it instructive that Microsoft - the entity largely responsible for the promulgation of the flawed usage - now advocates not using HN. Msdn.microsoft.com/en-us/library/fzcth91k%28VS.71%29.Aspx – Throwback1986 2 days ago 3 The reason Hungarian notation conveying type ("systems notation") is frowned upon in Python is simple.

It's misleading. A variable might be called iPhones (the integer number of phones, maybe :-) but there's nothing at all to keep you from putting something other than an integer into it! And maybe you will find you need to do that for some reason.

And then all the code that uses it is very misleading. – kindall 2 days ago 1 I've posted a (slightly expanded version) of it. – kindall 2 days ago.

IMHO, it never(*) makes real sense to use Systems Hungarian (prefixing the data type). Either you use a static language or a dynamic language, but with both the compiler or interpreter takes care of the type system. Annotating the type of a variable by means of the variable name can only cause ambiguity (e.g. Imagine a float called intSomething).

It is completely different with regard to Application Hungarian, i.e. Prefixing with some kind of usage pattern. I'd argue it is good practice to use this kind of notation, e.g. 'usValue' for an unsafe (i.e.

Unvalidated) value. This gives a visual cue as to the usage and prevents you from mixing different uses of variables which do have the same type but are not intended to be used together (or when they are intended to be used together, you at least have an idea as to what is being used and they produce a blip on your code checking radar). I frequently use such a thing in MATLAB, e.g. IdxInterest to indicate that the array of doubles are not raw data values, but just the indexes (into another array) which are of interest in one way or the other.

I regularly use selInterest (sel from select) to do the same with logical indexes (I agree this might look like borderline Systems Hungarian), but in many cases both can be used in the same context. Similarly for iterators: I regularly use multidimensional arrays (e.g. 4D), in the odd case I run a (par)for over a dimension, the iterators are called iFoo, jBar, kBaz, ... while their upper limit is generally nFoo, nBar, nBaz, ... (or numFoo, ...). When doing more complicated index manipulation, you can easily see what index belongs to what dimension (by the prefix you know what numerical dimension is used, by the full name you know what that dimension represents).

This makes the code a lot more readable. Next to that, I regularly use dFoo=1;, dBar=2;, ... to denote the number of the dimension for a certain set of variables. That way, you can easily see that something like meanIncome = mean(income, dBar) takes the mean income over the Bars , while meanIncome = mean(income, 2) does not convey the same information.

Since you also have to set the dVariables, it also serves as documentation of your variables. While it is not technically incorrect to do something like iFoo + jBar or kBaz + dBar, it does raise some questions when these do occur in your code and they allow you to inspect that part more vigilantly. And that is what real (Applications) Hungarian Notation is all about.

(*) The only moment where it might make some sense, is where your complete framework/language asks you to use it. E.g. The win32 API uses it, so when you interface with that directly, you should use those standards to keep confusion to a minimum.

However, I'd argue that it might make even as much or even more sense to look for another framework/language. Do note that this is something different from sigils as used in Perl, some BASIC dialects etc.These also convey the type, but in many implementations this is the type definition so no or little ambiguity is possible. It is another question whether it is good practice to use that kind of type declaration (and I'm not really sure about my own stance in this).

Applications Hungarian FTW! – Jonas 2 days ago It may well serve in Fortran with implicit typing. – Vladimir F yesterday @VladimirF: as far as I see, implicit typing is just a commodity, syntactic sugar if you like.

When you use Systems Hungarian Notation, you might as well do The Right Thing® and properly define the type as to have the compiler working for you and detect any relevant errors. IMHO Systems Hungarian Notation even reduces the advantages of implicit typing (since you attach a type non-formally) while only adding disadvantages such as possible inconsistencies. Feel free to argue, as I don't have experience with Fortran and its implicit typing.

– Egon Geerardyn 3 hours ago.

As it was proposed, Hungarian notation is a reasonable idea. As it was applied? It should be nuked from orbit (It's the only way to be sure.).

The accepted answer from the first question you link to applies the same to Python: Hungarian notation has no place in Java. The Java API does not use it, and neither do most developers. Java code would not look like Java using it.

All this is also true for Python.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.