Return to Answer

HECK NO!

Don't use Hungarian notation or any other notation. As programmers, we shouldn't be using "notation" for our variable names.

What we should do is name our variables well:

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.

• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.

• When zeroing in on how general or specific a name should be, consider the domain it is in and the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then it is fine to come up with a prefix or suffix to denote that difference. Keep it as short as possible.

As other answerers have said, it is this narrow case that started "Apps Hungarian", to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft! In fact, why not use Jörg W Mittag's idea of making an actual new type out of it? Then you can't possibly get things mixed up.

In almost any area, adding stuff that has minimal meaning density reduces the overall meaningfulness and ease of comprehension. Here's one example from Ben Franklin. And another example: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

By adding information, I made that a complete pain to read.

So forget notation. Forget special prefixes that you always add. In my opinion, the only real guideline here should be:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.

HECK NO!

Don't use Hungarian notation or any other notation. As programmers, we shouldn't be using "notation" for our variable names.

What we should do is name our variables well:

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.

• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.

• When zeroing in on how general or specific a name should be, consider the domain it is in and the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then it is fine to come up with a prefix or suffix to denote that difference. Keep it as short as possible.

As other answerers have said, it is this narrow case that started "Apps Hungarian", to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft! In fact, why not use Jörg W Mittag's idea of making an actual new type out of it? Then you can't possibly get things mixed up.

In almost any area, adding stuff that has minimal meaning density reduces the overall meaningfulness and ease of comprehension. Here's one example from Ben Franklin. And another example: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

By adding information, I made that a complete pain to read.

So forget notation. Forget special prefixes that you always add. In my opinion, the only real guideline here should be:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.

HECK NO.

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.
• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.
• For help in zeroing in on how general or specific a name should be, you have to consider the domain it is in, the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then come up with a prefix or suffix to denote that difference. Keep it as short as possible. It is this narrow case that started "Application Hungarian notation", as other answerers have said, where they needed to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft!

In almost any area, adding stuff that has minimal meaning reduces the overall meaningfulness. Here's one example from Ben Franklin. And another: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

HECK NO!

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.

• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.

• When zeroing in on how general or specific a name should be, consider the domain it is in and the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then it is fine to come up with a prefix or suffix to denote that difference. Keep it as short as possible.

As other answerers have said, it is this narrow case that started "Apps Hungarian", to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft! In fact, why not use Jörg W Mittag's idea of making an actual new type out of it? Then you can't possibly get things mixed up.

In almost any area, adding stuff that has minimal meaning density reduces the overall meaningfulness and ease of comprehension. Here's one example from Ben Franklin. And another example: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

HECK NO.

Don't use Hungarian notation or any other notation. As programmers, we shouldn't be using "notation" for our variable names.

What we should do is name our variables well.

This means:

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.
• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.
• For help in zeroing in on how general or specific a name should be, you have to consider the domain it is in, the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then come up with a prefix or suffix to denote that difference. Keep it as short as possible. It is this narrow case that started "Application Hungarian notation", as other answerers have said, where they needed to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft!

In programming, adding any stuff that has minimal meaning reduces the overall meaningfulness of the code. Here's an example. It is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

Isn't it weird that by adding information, I made that a complete pain to read?

So forget notation. Forget special prefixes that you always add. In my opinion, the only real guideline here should be:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.

HECK NO.

Don't use Hungarian notation or any other notation. As programmers, we shouldn't be using "notation" for our variable names.

What we should do is name our variables well:

• Avoid too general names. Don't name it z when it's a class variable representing a named object, say, a phone bill. Call it phoneBill or PhoneBill.
• Avoid too specific names. When something is clear without additional information don't include it. If it's just a string index variable for looping through the characters of a string, and you only use it once in function MyFunc, why on earth would you ever call it MyFuncTempStringCharacterIndex? That's a sad joke. Call it Pos or even i if you like. In context, the next programmer will easily understand what it means.
• For help in zeroing in on how general or specific a name should be, you have to consider the domain it is in, the context of other possible meanings. In the narrow case where there are two easily confused, similar type items that are used in the same way, then come up with a prefix or suffix to denote that difference. Keep it as short as possible. It is this narrow case that started "Application Hungarian notation", as other answerers have said, where they needed to distinguish between measurements relative to the window rwTabPosition and relative to the document rdTabPosition. But in an application that does everything relative to the document, don't add any extra cruft!

In almost any area, adding stuff that has minimal meaning reduces the overall meaningfulness. Here's one example from Ben Franklin. And another: it is possible in English to decorate our words with their part of speech. It's more information, isn't it? In case beginners to English got confused, it could be really helpful to them, right? Read this and tell me how useful you think this is to long-term comprehension and the efficient impartation of information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

By adding information, I made that a complete pain to read.

So forget notation. Forget special prefixes that you always add. In my opinion, the only real guideline here should be:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.