You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
If you were trying to modify or debug this code, you'd be at a loss unless you could read the author's mind. Even if you were the author, a few days after writing this code you might not remember what it does because of the unhelpful variable names and use ofmagic numbers.
Looking at scientific programming codes, it is often to see examples like above (or worse): code with variable names such asX,y,xs,x1,x2,tp,tm,cif,reg,xi,yi,ii and numerous unnamed constant values.
What Makes a Bad Variable Name?
Summarizing that, most problems with naming variables stem from:
A desire to keep variable names short
A direct translation of formulas into code
On this first point, while languages like Fortran did limit the length of variable names (to six characters), modern programming languages have no restrictions so don't feel forced to use contrived abbreviations. But it is not recommended to use long variable names (always thinking aboutreadability).
Let's see an example that makes both mistakes. Say we have a polynomial equation for finding the price of a house from a model. You may be tempted to write the mathematical formula directly in code.
temp=m1*x1+m2* (x2**2)final=temp+b
This code looks like it was written by a machine for a machine. While a computer will ultimately run your code, it'll be read by humans, so write code intended for humans. To do this, we need to think not about the formula itself (the how) and consider the real-world objects being modeled (the what). Then, rewriting the last example: