Ironically, from personal experience the main scenario I have seen Hungarian used is either "cargo-cult" programming i. NET to work around the fact the language is case-insensitive e. NET controls and that's really a matter of choice.
I feel some kind of naming convention should be used for controls as there can be multiple controls that display the same data. I'll just focus on SQL Server since you mentioned it. I see no reason to put 'tbl' in front of a table. You can just look at any tSQL code and distinguish a table by how it is used.
Tables could be confused with a View, but when it comes to how they are used; there is no difference, so what is the point? Variables can present a problem, but they need to be declared and really, how far from your declare statement do you plan on using a variable?
Scrolling a few lines shouldn't be that big of a deal unless you're writing very long procedures. It may be a good idea to break up the lengthy code a little. What you describe is a pain, but the Hungarian Notation solution doesn't really solve the problem. You can look at someone else's code and find that the variable type may get changed which now requires a change to the variable name.
Just one more thing to forget. And if I use a VarChar your're going to need to look at the declare statement anyway to know the size. Descriptive names will probably get you further. PayPeriodStartDate pretty much explains itself. Another thing to add is that, what abbreviations would you use for an entire framework like.
Yeah, it's so simple to remember that btn represents a button and txt represents a text box. However, what do you have in mind for something like StringBuilder? What about CompositeWebControl? Do you use something like this:. One of the inefficiencies of the Hungarian notation was that, by having larger and larger frameworks, it proved not only not to add extra benefit, but also to add more complexity for developers, because they now had to learn the nonstandard prefixes more and more.
To my way of looking at things, Hungarian Notation is a kludge to get around an insufficiently powerful type system. In languages that allow you to define your own types it's relatively trivial to create a new type that encodes the behavior you're expecting. In Joel Spolsky's rant on Hungarian Notation he gives an example of using it to detect possible XSS attacks by indicating that a variable or function is either unsafe us or safe s , but that still relies on the programmer to visually check.
If you instead have an extensible type system you can just create two new types, UnsafeString and SafeString, and then use them as appropriate. As a bonus, the type of encode becomes:.
If all your output functions then only take instances of SafeString it becomes impossible to output an un-escaped string [ baring shenanigans with conversions such as StringToSafeString someUnsafeString.
ToString ]. It should be obvious why allowing the type system to sanity check your code is superior to trying to do it by hand, or maybe eye in this case. In a language such as C of course, you're screwed in that an int is an int is an int, and there's not much you can do about that. You could always play games with structs but it's debatable whether that's an improvement or not. As for the other interpretation of Hungarian Notation, I. Hungarian notation is almost completely useless in a statically typed language.
It's a basic IDE feature to show the type of a variable by putting the mouse over it, or by other means; moreover you can see what the type is by looking a few lines up where it was declared, if there's no type inference.
The whole point of type inference is to not have the noise of the type repeated everywhere, so hungarian notation is usually seen as a bad thing in languages with type inference. In dynamically typed languages, it can help sometimes, but to me it feels unidiomatic. How do you express a polymorphic variable that can be an integer or a string in hungarian notation?
The only place I've ever used hungarian notation was in assembly code, because I was trying to get back what I'd get if I had a type system, and it was the first thing I've ever coded.
Anyways, I could care less what people name their variables, the code will probably still be just as incomprehensible. Developers waste way too much time on things like style and variable names, and at the end of the day you still get a ton of libraries with completely different conventions in your language. I'm developing a symbolic i. I don't know what tools you're using, but last time I was forced to work in an environment that didn't provide this feature was in the 20th century, the language was COBOL, oops no it was Fortran, and my boss didn't understand why I left.
A bit integer may become a bit integer at some point, for good reasons that had not be detected at the start of project. So, renaming intX into longX or leaving it with a name that points to the wrong type is bad karma. Redundancy is not very good design pattern or habit. Even humans are reluctant to too much redundancy.
I believe being in dire need of hungarian is a symptom. A symptom of too many global variables If your variable definition isn't in sight, usually, you've got trouble. And if your functions don't follow some memorable convention , there again, big trouble.
It originated on languages that needed it. On times of global variables bonanza. The only real use we have for it today is the Joel Spolsky one. To track some particular attributes of the variable, like its safety. Some other answers talked about editor functionalities that helped seeing the type of a variable as you hover on it.
In my view, those too are kind of problematic for code sanity. I believe they where only meant for refactoring , as many other features too, like function folding and should not be used on new code. I think the reasons not to use Hungarian notation have been well covered by other posters.
I agree with their comments. With databases I use Hungarian notation for DDL objects that are rarely used in code, but would otherwise collide in namespaces. Use a consistent method to name these objects and you should be able to run some validations by querying the metadata. In former times, when all you had was string, int, bool and float, the characters sibf would have been sufficient.
While names are almost always strings - aren't they? What's with a Street class? Names get longer and longer, and even if you use CamelCase, it is hard to tell where the type-prefix ends and where the variable-name begins.
Okay - you could use underlines, if you don't use them for something else already, or use CamelCase if you used underlines so long:.
Either you will end in using useless prefixes for trivial cases, like loop-variables or count. When did you recently use a short or a long for a counter?
If you make exceptions, you will often loose time, thinking about needing a prefix or not. If you have a lot of variables, they get normally grouped in an object browser which is part of your IDE.
The int doesn't tell us very much. The mere fact that something is an int doesn't tell us what's in it. Now let's suppose, instead, we call it like this:. This is fine as long as you know what c stands for.
But you'd have to have a standard table of prefixes, and everyone would have to know them, and any new people would have to learn them in order to understand your code. Whereas customerCount or countOfCustomers is pretty obvious at first glance.
This is bad, but the compiler wouldn't tell you so. So if you used Hungarian, at least you'd have some indicator of what was happening:. NET, with static typing, this isn't necessary. And Hungarian was too often used as a substitute for good naming. Charles Simonyi was an originator of two programs we? The Hungarian notation method of naming variables was part of his doctoral thesis before he introduced it, and it was adopted widely as a standard within Microsoft.
We know what a giant Microsoft is, and it? Of all the reasons Mr. Simonyi gives for creating Hungarian notation, the use case that stands out most to me is to provide further clarity for the? In my job as a developer in a large enterprise, I? Large enterprise companies are warehouses for decades-old legacy code that no one wants to touch.
Generally, if there? When you? In general, it? Submitting a pull request with generic variable names that mean nothing to our human readers is condemnable. Following standards and best practices makes our code readable, and Hungarian notation is just one of many standards and best practices.
Hungarian notation hasn? Computer languages are different. These differences are vast and span across a wide range of how variables are used, types of variables, scope of variables, and the variables? In a strongly-typed language, like C or Java, our types are enforced by our declarations and then the compiler at compile time.
Because of the strict compiler, the notation is adding redundancy and length to our code. Or from a more subjective approach, the notation confuses the readability of our code by adding strange type notation to our variable names, and that? But for loosely-typed languages, like JavaScript or Perl, putting type values in our variable names would definitely help, right? Unfortunately, the notation falls short again for similar reasons.
While it helps us determine the type of the variable, does the type really even matter? When we use loosely-typed languages, we? Charles Simonyi was trying to bring clarity to an issue he dealt with in his craft.
Hungarian notation shines a light on this issue that all developers face, and it? Here are some of my favorites, not just because they help readability in my code but because they also help the?
It can? Most of us developers think of our code as a work of art, so why would we litter it with repetitive type declarations and long variables? Writing good, clean code is a craft we developers take great pride in, and more importantly, our code tells the story of a problem we? When we standardize code style, our code loses identity and our craft becomes makeshift. While this is certainly not the intent of Hungarian notation or other standards and best practices, let?
Rick Beley has written software for over 20 years, mostly for large enterprises.? Most recently, he has spent time as a development lead on two large web applications.? Rick is also a total geek for data, processes, and diagrams, and he loves to measure, improve, and automate just about anything he can.? Also very important in complex programming is to make visible the difference between source data and derived data, so it is clear to the programmer when he is doing interpretation of derived data — keeping in mind that it is better to do interpretation on the source data not on derived data if possible.
For instance, prefix variable names with underscore if the variable holds derived data. So we still use Hungarian Notation in that project but not in other projects that work on newer IDEs.
The notation hints directly -and succinctly- about the available indirection levels on a variable, and IMHO helps to build a mental pattern that simplifies writing pointer-centric code. Big mistake IMHO. Comments do not explain what your code does as you say, the code does that. They actually explain what your code is intended to do and as such are an aid to correctness and also debugging and should therefore be liberal, not sparse.
Yes, it is important to explain what the code is supposed to do. Even more important though is explaining the context in which the code is expected to run.
What are the assumptions about the environment? What needs to be initialized first? Does order of initialization or execution matter?
Given the primitive tools of the time Hungarian notation really did make code easier to read. Now, like the author says, use descriptive nouns with casing or underscores to aid readability. The difference is substantial.
Systems Hungarian is the mixed-up, basically useless misunderstanding of Hungarian notation popularized in the Win32 API that most people including, obviously, this article think of when they talk about it.
But knowing that displayName comes from unsanitized data? Yes exactly. Hungarian was designed to distinguish things that are stored in the same type but otherwise unrelated. The article completely misses the point. I personally do not like Hungarian notation. Modern IDEs are super advanced, you can easily figure out the type by hovering your mouse cursor over the variable. I can't think of any case where Hungarian notation can be helpful.
It does more harm than good. Right now, we know that the MTA client will only compile on x86 MSVC, but maybe in the future, like 10 years later, we have GTA:SA fully reversed, and then porting the x86 code to x64 will look very stupid since we hardcoded the type names in the variables.
This can be avoided:. No, that's something I can get behind. I don't see any problem with. It's simple, readable, maintainable, and gets the job done. Imagine throwing std::pair or std::tuple everywhere, sounds like a nightmare. It might be good in edge cases, but not in most cases. Anyways, I don't want to go off topic, since this isn't related to hungarian notation anymore.
Beta Was this translation helpful? Give Feedback. Skip to content. Star Should we continue using Hungarian notation? Return to top. Hungarian notation in variables I personally feel like we should stop using it, as its redundant, and when something needs to be refactored it introduces a lot of unnecessary code changes, which makes it harder to review code if a variable is used in a lot of places.
How was Hungarian notation intended to be used? Should we continue using it? Probably not As discussed earlier Im very much in favor of dropping it altogether stopping to use it, but, its not my decision of course, but Im pretty sure all of us wants to drop it, and if its used by anyone its so the code is consistent with old code, but, again, as discussed, most of the time hungarian notation isnt consistent in itself What should we keep?
Oldest Newest Top. I haven't thought about dropping the S , C or [eE] prefix for typenames. My personal preference is not to drop it. Having very short 3 line functions that don't use Hungarian notation is OK. I think our practical uses of unions makes this a non-issue. Other than unions, how is our use of Hungarian notation inconsistent? Collaborator Author. On Discord, qaisjp said: Hungarian notation helps you read code because you don't need to commit the type to memory As mentioned above, we have powerful IDE's whom take care of this for us.
We wont be using any notations, so theres no mixing. What do you mean? No notations is also notation, imho. Yes, but, having code where we dont consistently use prefixes because there are no viable prefixes for some types isn't better either imho: A good example would be std::vector.
Programming is not about types itself. It's more about operations with them. I agree with you. This is what I was trying to explain. My two cents on this discussion: I agree that Hungarian notation by itself does not make the code much more clearer or easier to understand.
Sign up for free to join this conversation on GitHub.
0コメント