My code refactoring algorithm

You're looking at a block of Python code. It's not immediately obvious what it does. It's sort of a mess and you realize it needs to be refactored. But how? What mental algorithm do you use?

Here's a trick I just figured out how to put into words. You first add comments to your code to make it easier to explain what it's doing in each part. Then you restructure the code until those comments are no longer necessary, using the comments as a guide to creating high level constructs that not only tuck complexity neatly away, they also explain the purpose of the surface.

What tricks do you use? 


Guest's picture

Umh, I don't get what you mean. If you always chose the right names for indentifiers and care about the common guidelines (not to much identation levels, useful sparse comments, etc) you don't need to refactor code because "readability" problems.

Liraz Siri's picture

Implementing the "common guidelines" will bring you a long way, but I find that often isn't enough. The point I was trying to make is that truly readable code shouldn't need any explanation / comments. If it does, I take that as a signal that something is wrong.
Victor Fontes's picture

Finally somone actually put that in words :)

Ilya Vassilevsky's picture

I find it useful to code when you know it is under version control. And you know you will eventually need to read patches and stuff. This makes you write shorter lines, break your expressions into more lines. This improves readability a lot.

Liraz Siri's picture

I started using version control about a decade ago (RCS integrated with Emacs) and found it immediately improved my productivity. By a lot. Suddenly it was much easier to spot exactly what I had changed since the last revision. Nowadays I try to make all my commits self-contained and self-documenting. Thankfully I don't use RCS any more. Git is much nicer.


Add new comment