<<Clean Code>> Quotes: 14. Successive Refinement

Args Implementation

Args is very simple to use. You simply construct the Args class with the input arguments and a format string, and then query the Args instance for the values of the arguments.

How Did I Do This?

If we have learned anything over the last couple of decades, it is that programming is a craft more than it is a science. To write clean code, you must first write dirty code and then clean it.

Args: The Rough Draft

So I Stopped

Having just added the String and integer arguments, I knew that each argument type required new code in three major places

Many different types, all with similar methods — that sounds like a class to me.

On Incrementalism

One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement… The problem is that it’s very hard to get the program working the same way it worked before the “improvement”.

To avoid this, I use the discipline of Test-Driven Development.

So I proceeded to make a large number of very tiny changes. Each change moved the structure of the system towards the ArgumentMarshaler concept. And yet each change kept the system working.

String Arguments

Putting thins in so you can take them out again is pretty common in refactoring.

Moving ArgsException into it’s own module means that we can move a lot of the miscellaneous error support code into that module and out of the Args module. It provides a natural and obvious place to put all that code and will really help us clean up the Args module going forward.

Much of good software design is simply about partitioning — creating appropriate places to put different kinds of code.

Conclusion

It is not enough for code to work. Code that works is often badly broken.

Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down.

Of course bad code can be cleaned up. But it’s very expensive. As code rots, the modules insinuate themselves into each other, creating lots of hidden and tangled dependencies. Finding and breaking old dependencies is a long and arduous task.