Chapter 3. Style
Okay, so ten out of ten for style, but minus several million for good thinking, yeah?
Zaphod Beeblebrox
In this chapter, we’re going to take a look at five ways I’ve hurt myself with bad style. These are the sorts of things that can seem like a good idea at the time, but will make code hard to read and hard to maintain. They don’t break your programs, but they damage your ability to work on them.
Hungarian Notation
A great way to lie to yourself about the quality of your code is to use Hungarian Notation. This is where you prefix each variable name with a little bit of text to indicate what kind of thing it’s supposed to be. Like many terrible decisions, it can start out innocently enough:
strFirstName intYear blnSignedIn fltTaxRate lstProducts dctParams
Or perhaps we read part of PEP-8 and decided to use underscores instead, or like suffixes more than prefixes. We could make variables like these:
str_first_name products_list
The intent here is noble:
we’re going to leave a signpost
for our future selves
or other developers
to indicate our intent.
Is it a string?
Put a str
on it.
An integer?
Give it an int
.
Masters of brevity that we are,
we can even specify lists (lst
)
and dictionaries (dct
).
But soon things start to get silly
as we work with more complex values.
We might conjoin lst
and dct
to represent a list of dictionaries:
lctResults
When we instantiate a class,
we have an object, so obj
seems legit:
objMyReallyLongName
But that’s an awfully long name, ...
Get How to Make Mistakes in Python now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.