Make your variable names meaningful. Don't use abortions like Hungarian notation. Avoid obscure abbreviations and when you do use them use standard consistent abbreviations so that everyone can understand your code.

Bad code: for(i=0;i < j;i++){ /*stuff*/}

Good code: for (ThisBox=0; ThisBox < TotalNumBoxes;ThisBox++){ /*stuff*/}

Well, it's all well and good to eschew Hungarian notation if you're developing on some flavor of Unix, or other non-MS OS (and good for you, I might add,) but if you do develop applications for Windows you're going to be forced to use Hungarian notation just to interface with the SDKs. And in this case, using standard and consistent abbreviations means using Hungarian notation, unless you want your code to look schizophrenic. With only a minor amount of acclimatization, Hungarian notation is much less intimidating and confusing. But writing a node about meaningful variable names that blasts Hungarian notation is a little bizarre. For example, given the following variables:

  • ThisBox
  • iThisBox
The second one is immediately recognizable as an integer value, wherever it is found, while you'll have to go to the variable definition for ThisBox if you ever forget. Maybe a better way to put this would be, use meaningful variable names that are consistent in style and composition with the rest of your code. This brings us to coding style. Please try to adapt your coding style to that of the other programmers/source code you are working with, or things get much more confusing. Conventions such as "all variables start with lower case letters" or "prefix all member variables with m_" become horribly confusing if used haphazardly throughout the code. Staying with conventions already established or agreed upon makes your variable names much more meaningful.

As a side note, the usefullness of Hungarian notation has diminished in this modern age of tolerable IDE's. It's not uncommon to be able to find the type of any kind of variable just by hovering the mouse over it. However, this doesn't reduce the importance of consistency, and it won't help you if you are looking over a printout of the code.

Log in or register to write something here or to contact authors.