Favorite ways to write bad Python

I've written some BAD code.

I mean, 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 the abominations I've created myself over the years, 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 I 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.

(I have some ideas for how to shorten this cycle. I might talk about them in a future email.)

"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've improved as a programmer.