Variable Declaration For Champions
Ralph Waldo Emerson once said, “Foolish consistency is the hobgoblin of little minds.” This quote was famously adopted in Python’s official style guide PEP8 by Guido van Rossum. What Emerson and by extension Guido are saying is: don’t let what you used to think cloud you from changing your mind once a better idea comes through. One aspect of programming that tends to be a fantastic example of foolish consistency is variable declaration.
Many students tend to take a simple and carefree approach to declaring variables. That is not an issue when the scope of the entire program is twenty-three lines. The real problem arises when a junior programmer takes the same carefree approach in the industry with an active code base. This article will outline the good, bad, and best steps to take when naming variables.
The Bad
Many beginners start their journey into programming with a tutorial. The instructor will write a quick example and assign that piece of code to a single-letter variable. While that’s great for seasoned programmers who only want to see the code in action, it sets the wrong example for someone stepping foot into the world of software engineering.
These are bad variable declarations because:
- They say nothing about what the code you’re referring to actually is.
- They can confuse other programmers who will eventually review your code.
- They are hard to read and don’t grasp attention.
The Good
Other programming languages that preceded Python had their own recommended way of variable naming conventions. These methods help with readability and clarity for other programmers.
These conventions are mostly upheld by programmers transitioning into Python from languages like Java and JavaScript.
These naming conventions are a tremendous improvement over the previous bad examples. However, there are even better ways to name your variables so that the entirety of the code is described in a variable.
Best Practices
Python is a dynamic language. Data types are inferred, and it becomes difficult to know what type they are unless you see the declarations themselves. The most practical way to solve this issue is to name your variables in a way that makes it obvious what data type it is just by reading the name. There are a few ways to do this.
The benefit of Hungarian notation is that by simply looking at a name such as fPrincipalValue, you can quickly determine that it is a floating point number that will hold a principal investment in some finance program, all from a variable name. Replace fPrinicipalValue with X, and you step into a world in which you suffer for the sake of suffering.
Another approach is to name your variables in what I coined Hungarian Snake Case. Prefix your variable with whatever data type is assigned to it while following the PEP8 guidelines. The Hungarian notated fPrincipalValue becomes f_principal_value and adds a level of readability without any drawbacks. Additionally, you can use an abbreviated version of the type flt_principal_value or str_username for further readability.
Consistency Without Foolishness
Whatever style you adopt is only as beneficial as your consistency in using it. The key is always to have the same naming style across a project. A programmer assigned to work on your code will quickly adapt to your style and become immediately effective, and you don’t lose your composure when revisiting it.
