My Law #1: DRY .. or not

I think that’s the rule that drives my programming style the most is:

#1: Keep it DRY: Don’t Repeat Yourself

more here http://media.pragprog.com/articles/may_04_oo1.pdf from smarter than me

But there are 2 very different parts of the code where DRY might and might not be applied: programmer’s code and “high level” domain logic

A) Programmer’s code

I say, it’s a place quite deep in your code, rather related to implementation and less to design. Those are rather controllers and views, and deep parts of model implementation, every helper and utility class. Details far away from actual functional requirements, use cases, business logic.

So there – in programmer’s world – I spend lots of time thinking how not to write the same/similar code twice. Really, I can even spend 10 hours or few days of thinking and writing ZERO code..
.. because I’d rather shoot myself in a foot with a railgun than used dumb-COPY-&-PASTE. We nowadays know it’s PLAIN WRONG, do we..

  • copy & paste exact parts of code is lazy (“lazy” the wrong way as opposite to being positively lazy as in yagni)
  • copy & paste similar parts of code might look and is quick solution at first, but it’s not. Someone WILL try to understand and refactor it later and WTF you
  • it’s about respect to other developers
  • it’s about write-once, read-100-times. It’s been always this way. So why bothering people after you with your unsolved problems
  • copy & paste is a smell for immediate action: extract similar code into a method, pass parameters, whatever.. make duplication gone
  • and obviously if a change must be later done to all duplicates, it must be made in X places instead of ONE

So this is BAD code. Effect of dumb COPY&PASTE&CHANGE-ONE-VAR

B) Domain Code

.. we must make distinction on the “A)” code made for programmers and “B)” code meant to describe our natural world, our domain specific requirements.
This is a “high-level” domain code, possibly close to what customer say and do; to what their use cases describe. So it should really tell what it does.

Such code should not distract reader by forcing the reader to jump & dive around in & out of methods to see how things are implemented. I’d have all code served in front of me instead

In my opinion in domain code it is more important to see the intent of the code than to be pure DRY. I must admit I don’t make some strict rule on that yet. It’s rather my intuition today.

Applying all the fancy programming patters and refactorings just to make code few lines shorter does opposite and makes intent, the flow, the algorithm not clearly visible.

I say there are 2 cases where I’m not always fully DRY

  • acceptance tests – simulating user interacting directly with application (via browser mouse clicks, keyboard, triggering events, etc)
  • use cases – the most important domain code, domain algorigthms, business logic

So I would live with such code..

.. and I think I would also live with this one, but maybe bit less comfortable in the long term..
..although at first those 3 cases now look shorter and more readable, but they also PRETEND that they do something by a nice method naming. In fact those methods might do sth completely different. They hide details, but those details ARE IMPORTANT, so should not be hidden

PS. .. methods longer than 10-20 lines might be OK for domain code, but they’re rather on the longer side