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 live online training, plus books, videos, and digital content from nearly 200 publishers.