DEV Community

Cover image for Variables names don't need their type
Waylon Walker
Waylon Walker

Posted on • Originally published at waylonwalker.com

Variables names don't need their type

So often I see a variables type() inside of its name and it hurts me a little inside. Tell me I'm right or prove me wrong below.

Examples

Pandas DataFrames are probably the worst offender that I see

# bad
sales_df = get_sales()

# good
sales = get_sales()
Enter fullscreen mode Exit fullscreen mode

Sometimes vanilla structures too!

# bad
items_list = ['sneakers', 'pencils', 'paper', ]

# good
items = ['sneakers', 'pencils', 'paper', ]
Enter fullscreen mode Exit fullscreen mode

Edge Cases?

It's so common when you need to get inside a data structure in a special way that itsn't provided by the library.... I am not exactly sure of a good way around it.

# bad ??
sales = get_sales()
sales_dict = sales.to_dict()

# good
🤷‍♀️
Enter fullscreen mode Exit fullscreen mode

Containers are plural

Always name your containers plural, so that naming while iterating is simple.

prices = {}
items = ['sneakers', 'pencils', 'paper', ]
for item in items:
   prices[item] = get_price(item)
Enter fullscreen mode Exit fullscreen mode

Before I start fights 🥊 in code review, am I inline here or just being pedantic?

👇 NOW DISCUSS

Top comments (13)

Collapse
 
ashuk profile image
Ash

"Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer" - Linus Torvalds

With modern tools and IDE's I really don't see this having to be a thing anymore. If you can just hover over or cursor to a variable and know its type. Then there is no need to add a type affix. Sadly I still do see this in the wild. Either due to an old code base or an old mindset and almost always when I do come across it there are at least a few dozen variable names that have since changed and have not been updated.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

That beside, if you can't tell the semantic meaning of a variable by its name, and thereby deduce the like type(s) in use, you need better names anyway.

For example, what is the type of is_ready? How about like_count? average_temp? pending_requests? (If you guessed "boolean", "integer", "float", and "something akin to a queue", you're right!)

Collapse
 
waylonwalker profile image
Waylon Walker • Edited

Duck typing 🦆

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

Which reminds me of something I put in my upcoming Python book...

In other words, Python doesn’t care if it’s actually a robotic duck, or a moose in a duck costume; if it has the traits needed, the rest of the details are usually a moot point.

Collapse
 
waylonwalker profile image
Waylon Walker

I had no idea what Hungarian notation was. That is an amazing quote.

Just today I had vscode (pyright in particular) catch me with an edge case. I had a function that would return an iterable if there were values, but False if there were none. It caught me that I wasn't catching the False case.

Collapse
 
clairec profile image
Claire Collins • Edited

It needs to be kept as simple as possible. That is the beautiful thing about Python. As long as your code is easy to read and understand, not just by you, but to all else that read it.
When I was going through my course the variables were often referenced with their type, but that just made the learning easier and less confusing whilst learning different types/classes etc.
When you actually start to write your own code then the naming with type is just an incredibly long drawn out process, unnecessarily. If it is a list, you know it's a list because the data is in [ ]. A dictionary is contained within { } so no need to call it a dict as it is obvious with key value pairs.
Some people may still want to use variable types when naming them. You gotta do yourself a favor from a time point of view surely!!
Simple, easy to understand and flowing. I'm a little OCD so I agree with you completely on this one.

Collapse
 
waylonwalker profile image
Waylon Walker

Interesting point with the difference between courses and real work, I hadn't thought about that.

It's also a bit less obvious sometimes where variables are often coming in from other functions that we might no be familiar with.

Collapse
 
codemouse92 profile image
Jason C. McDonald

There's also the fact that a variable's type may change in the course of refactoring, or even executing, a Python program. Systems Hungarian notation is evil in production code.

Collapse
 
codemouse92 profile image
Jason C. McDonald

Apps Hungarian is an example of good practice, e.g. distinguishing between otherwise identically named variables and functions relating to rows vs. columns in Microsoft Excel, which Charles Simonyi was working on when he invented it. The central tenant is that the prefixes relate to the semantic meaning.

Systems Hungarian was a total misunderstanding of the intent, wherein the type was stated in a prefix. Your post pretty well sums up why that's a terrible idea.

Collapse
 
sargalias profile image
Spyros Argalias

I agree ;)

Collapse
 
fronkan profile image
Fredrik Sjöstrand

So, in many cases I agree with you, especially for most of the built in structures.
For those there often exists some common naming patterna. I think dicts are a bit harder to name in general. I often think of names like key2value/key_to_value or keys_values but it is very context dependent. I must admit I also use df prefix/postfix for data frames at times. It is short and communicates that the data is in the shape of a table. I, in general, prefer using type annotations over baking the information into the name as they are kind of made for it.

Collapse
 
shiftyp profile image
Ryan Kahn (he/him) • Edited

I think it's a decision to be made as a group for the codebase. So gather diverse opinions and decide as a team (no fights)!

Collapse
 
waylonwalker profile image
Waylon Walker • Edited

Haha, I am too nice to actually start fights in code review. People already feel vulnerable enough. Good point basing it off of the group/codebase.