Clean code wankers

At a work related car trip my co-worker and I came up with term "clean code wanker". Well maybe my only contribution was to "help" him to formulate the idea with politically incorrect term. I tend to do that.

What is a "clean code wanker". It is a person who has read a book called "Clean code" or similar piece and is too dogmatic in his views. Don't get me wrong Clean code is great book by Robert Martin. There is no doubt about that. But this type of books have created people that could be called "clean code wankers". Clean code wankers tend to remember a lots of principals and other guidelines, but forgot the reasoning behind these things.

In programming word there are great principles with sharp acronyms like DRY and SOLID. Unfortunately it sometimes seems that the baby is thrown out with the bath water. For example don't repeat your self (DRY) is understood mostly to reduce duplicated code. And duplication is bad m'key?

But DRY-principle has actually more wider scope that can be overlooked: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. For example this means one should think re-structuring the whole traditional web-architecture where adding single field to the user interface requires adding things to all over the code base.

But let's concentrate on duplicated code. That is maybe the most often DRY-principle is mentioned. And yes, of course duplication is bad. However sometimes the cure is worse than the sickness. There could be two nearly identical lines of code and DRY-principle is brought to the discussion. In reality these two similar lines could just represent different "piece of knowledge". It is just the language structure that gets repeated and makes them look similar. Duplicating that structure can be annoying but the more complex solution that would remove the need for repetition could be harder to understand and maintain.

If one needs to write 100 lines of code for to remove 2 lines of duplicated code, it is mostly common sense to just suck it up and do the duplication. Unfortunately things are not so clear in reality. What if there are 100 lines of almost copy paste and alternative would be 90 lines of code using reflection. Sometimes code is just boring boilerplate to move data from one object to another:

a.setA(b.getA())
a.setB(b.getB())
a.setC(b.getC())

This could be easily avoided using reflection or code generation. Problem is that those are more much complex beasts. It requires more skilled developer to create and maintain those tools. These costs are not often thought when decision to minimize writing effort are done. And I think these things should be valued more. For example moving things around with reflection causes IDEs "find usage" to stop working reliably.

It is annoying write similar things a lot. But maybe during that mechanical work one can think why the structure of application requires moving data around this way at all. Automating something dumb does not make it smart. It just hides dumb.

Providing value through software does require quality code. And quality requires discussion about different approaches, code reviews and re-makes. Good code is fast and easy to work with and that does not happen by change. Reading books like Clean code definitely helps. However if "quality" becomes wanking between different approaches and school of thoughts, working is not fast anymore. It is filled with endless discussions comparing this and that way of doing the same thing. Quality code is not often about artistic expression, but ease of reading and understanding. Complicated ideas should be expressed with ease.

Don't be a clean code wanker, m'key?