marcov wrote:Hungarian notation is a sign of (1) a defective, too weak typed language (2) and unproductive IDE. Hovering above a variable can simply show declaration/type.
Well I've heard people argue that a language that requires an IDE to be productive is not necessarily a good thing.
I also hear a lot of people saying that you shouldn't need more than 1MB, and I don't believe them either.
And there are arguments for keeping functions short so that they can be understood quickly without requiring help from an IDE, and that can be actually tested as a unit.
Even then not all symbols used in the function are declared in the function, so this is an irrelevant argument.
And sometimes it's not the language itself that is the problem. Java, like C, is a very simple language syntactically, with few keywords. But the frameworks, design patterns, and methodologies used in Java are kind of grotesque to be honest. Some of that is dictated by the language's design. Like using classes as a means of defining namespaces.
Yes. And same in C++, Delphi or any grown up language. It is not even a OO thing, or framework thing, just about readiness to make very large programs over an extended period in time, so that you can't know every detail at every moment anymore. And work in teams, so that you didn't necessarily write all code.
The only time I really find an IDE necessary is when working with a large class library, such as Qt. Then it becomes very useful to navigate through the myriad of classes and their members. For my own code, I haven't needed to rely solely on the IDE to navigate my own code. Granted my projects are not that large.
But then you also don't need to employ Hungarian notation everywhere as hackety replacement for decent IDE codetools/intellisense.
C, C++, and Java are all strongly typed languages (albeit with implicit type coercion). I think hungarian notation is more of a corporate culture thing than a reflection on limitations of the language or tools used.
I agree there. I think it is something from the past (nineties). And somehow I somewhat agree with the principle of just keep it going as it is, as the problem is less than making MSDN a hodge podge of styles, or worse, renaming everything.
But that doesn't mean that MSDN using it is automatically some best practice (well, other than if your best practice is being consequent long term, and not bend to every IT fashion)
I dislike it personally, but understand why it's used. And when doing heavily object-oriented coding, I can understand why it would be desirable to use a prefix for a member variable. Although I think I prefer explicit scope selection in those cases.
Suff/Prefixes for various scopes (field, global variable, local var, parameter) is a different subject again. But I wouldn't go as far as stating that there is a one size fits all solution because it also depends on the language.
E.g. Delphi uses "f" prefix for fields, to keep the identifier without prefix free for properties, which is its preferred way of making state visible. It uses "a" for parameters of methods so that it won't clash with fields or properties in setter functions.
If you have a language without properties, this makes less sense. Also in some languages types and other symbols are in the same namespace, and some have a separate (sub-)namespace for types. Delphi has an unified namespace (though with some exceptions, mostly for MSDN interfacing), so types are generally prefixed with T