Hungarian Notation in Fortran

Question

Is it considered good or bad practice? A friend of mine told me that, generally speaking, it was not considered a good practice in most languages now a days, but that he thought he heard that this was not the case with fortran. Is this true? And if it is true, why?

Answer 1

In 30+ years of programming in Fortran I've never come across anyone using Hungarian notation. Your friend might be confusing Fortran's long-standing (and now deprecated) ability to implicitly type variables depending on the initial letter of their names. But that long predates widespread awareness of what is now called Hungarian notation.

On the more general issue of whether Hungarian notation is, or would be, a good idea for adoption when writing Fortran, I agree with David, and (I think) the wider software development community which regards it as a not-very-useful practice. Fortran certainly does not require it, variable (and other) names follow rules very similar to those in many programming languages.

Answer 2

Systems Hungarian

Systems Hungarian notation essentially adds type information into variable names so that you know the types of the values you are using, and are less likely to use a value in an incorrect way. This is of dubious benefit in modern strongly typed languages, as type-safety significantly reduces the chance of using/accessing a variable erroneously.

However, for less strongly typed languages, including this sort of information can be beneficial, as it keeps the programmer constantly aware of the data they are dealing with.

The biggest criticism of HN (besides it being of limited benefit in a strongly typed language) is that the type prefixes used can result in extremely obscure and confusing variable names, so while you may gain a measure of pseudo type-safety, you can lose clarity in the code (or at least create code that is only readable to be an expert in your conventions) which can harm maintainability.

If you need to produce code to someone else's naming convention then you have little choice, but if you are in control, you can define a sensible, clear, simple naming convention that may suit your needs better, giving a good balance between making variable names information-rich and introducing confusing clutter. For example, one practice is to name boolean variables in the form of IsOpen rather than Open, to avoid confusion between words that can be used as both verbs and nouns. It also makes it easy to see when you are mixing booleans into integer or floating point expressions. This approach also works intuitively, so requires no special knowledge for any programmer to be able to read and understand the code.

---

Apps Hungarian

In response to the first comment, there is another form of Hungarian Notation (Apps Hungarian). See Wikipedia for a more in-depth description of it, but essentially it associates information relating to the usage or purpose of a variable with its name, rather than its type.

In strongly typed languages this is a much more useful approach, and is well worth considering - or at least (IMHO) in concept. I find the prefixes chosen often tend to be rather complicated and unfriendly (e.g. rw instead of row to my mind just obfuscates the prefix without any practical gain). I also think many examples are rather pointless (e.g. str to indicate that a variable is a string, in many languages is redundant because strings are often only represented in one form, and if the variable is named sensibly ("UserName" rather than "Data") it is often a pretty obvious that it will be a string).

---

A Modern Alternative

In my opinion/experience, what usually matters is clarifying a few key differences between variables (e.g. we need to treat members, pointers, volatiles and constants quite differently from each other - mixing up a member and a parameter or indexing an array with the wrong index variable can be catastrophic, and modern compilers do little to protect us from these mistakes). The difference between a list and a string is usually obvious if sensible descriptive variable naming is used, and type-safe languages will tell us if we've mixed these types up, so we don't need prefixes for these cases. This led to my own extremely simple prefixing approach which is explained in my answer to this stack overflow question.

Hopefully this post may give you something to think about when deciding if prefixes will be beneficial for you. Ultimately, any prefixing scheme you apply needs to be something that you believe (or better, can prove) is beneficial to you and your team. Don't just follow someone else's scheme - think about how and why a prefix might be useful, and evaluate it objectively before you adopt it or discard it.

Answer 3

It really depends more on the development environment and the team standards than on the language. If you happen to be using Fortran, but in a good IDE with code analysis and navigation, then you probably don't need Hungarian Notation.

I think the real question to ask yourself is, "What would Hungarian Notation give me?"

That is, what is its value? Even when using an old language, you can still apply good coding practices and techniques. Keep routines small, keep variable scope small, etc. Now, I'm not expert in Fortran, so I don't know what the limitations are. But I imagine it would still hold true.

Hungarian Notation is particularly useful when you're using a limited editor (no information about the variable on mouse hover, for example) and when your variable has a fairly long lifespan. By which I mean the use of the variable continues well beyond its definition.

Since the inception of Fortran so long ago, we as an industry have learned a lot about organizing code and working effectively on development teams. (Even if the team is only you... Remember that any code you wrote more than a few months ago may as well have been written by somebody else.) You may be able to apply these lessons to your Fortran code.

Use informative variable names. Storage isn't expensive, characters don't take long to send over modems anymore... Reasonably long variable names are both acceptable and encouraged, provided that they convey information about what that variable is and means. Additionally, keep the use of the variable close to its definition. So the additional context of the surrounding code reveals more information about the variable than just its name.

In short, if you have a global variable called price used throughout the application, then calling it dblPrice to indicate that it's an double adds useful information to the variable name. But there are more meaningful ways to add that useful information. price is a poor name for a large-scope variable in the first place, and the scope may be able to be narrowed if possible.