My Favorite Ways To Write Bad Python

My Favorite Ways To Write Bad Python

Have you ever looked at code you wrote six months or three years ago, and ask yourself, “what in the world was I thinking?” We all have.

Pondering my own Pythonic abominations, I’ve noticed a few trends. I don’t want to say they’re my “favorites”, but I seem to do them a lot:

Overly Complex Algorithms

This is a big one. I look at the code I wrote - the classes, modules, etc. - and can see it works just fine.

But it could be WAY simpler.

Simpler often means more readable, more maintainable, and - surprisingly often - less fragile. I mean, the code still has to work correctly. But correct, simple code is nearly always better than correct, complex code.

When I step away for a while, and look at the code base again later with fresh eyes, often I see a much cleaner solution.

“Accidentally Working” Code

This one is kind of funny.

Reading the code, I can see what I was thinking at the time. And it actually works - meaning, it meets the requirements, it passes the unit tests, and it’s behaving like it’s supposed to.

But it’s clear that when I wrote that code, I totally misunderstood the problem I was writing code to solve.

Really, it should NOT work. Because I was writing code to solve a completely fictional problem, not the actual problem! But somehow, it solves both.

I admit being embarrassed this happens.

Still, I’m amazed that this happens at all, and more amazed that it seems to happen repeatedly.

Misleading Identifier Names

I put a LOT of effort in choosing good names for things. Variables, type and class names, methods, modules, et cetera.

That’s because our clarity on what’s going on is in direct proportion to how clearly we understand each component’s role. And picking good names for all those can help a lot.

But:

Even though I’ve been making this a front-and-center priority for years, I’ll often go back to refactor some code, or add a new feature or something, and think “I really should have named this SomeOtherName”.

Maybe the lesson is that enhancing readability is a never-ending process. We can always improve.

Missing Out

This one’s pretty interesting.

What I’ve found is that I can look at a code base I’ve written some time ago. And I’ll see that I could have used some technique to really improve the quality of the code. But I didn’t.

That “technique” can be a design pattern; an idiom; or maybe even a feature of the language. Almost always, it’s just because I didn’t know about it at the time.

With my current wisdom, it would have been a lot easier. And it would probably be more robust, maintainable, readable, etc.

The great thing when you notice this: It’s a sign you have improved as a programmer.

So celebrate when you notice all of these, and continue to learn from them.

The Powerful Python Newsletter is just for you. Like reader Charles Hayden puts it:

“I have seen a lot of books, articles, and newsletters over the years and yours is one of the best. Not just what you say about Python, but how to go about learning.”

Sign up here:

https://powerfulpython.com/newsletter-eza/