Balancing DRY and Readability¶
Some complexity belongs in your editor/IDE
I was writing a combination of setuphandlers and functional test fixtures recently when I found myself doing something noteworthy. I was converting both apparatus from a set of loops over content type names and prefixes to a few utility functions with lots of repetitious calls. Why was I violating DRY? Because I couldn’t make sense of things! Oh yeah, DRY should never compromise readability. :)
It’s definitely possible to take DRY too far leading to such slap-your-forehead moments as this. I think that setup code, whether for install or a test fixture, is particularly prone to this. I’ve both written a lot of setup code and read a lot of it in the wild where a bunch of complex structure is introduced in the name of DRY.
What I ended up doing was writing a small number of utility functions whose call signatures were intuitive and readable. Then I used a bunch of complex “M-x query-replace-regexp” commands in Emacs to convert the complicated structure into a simple, readable, flat, but nonetheless very repetitious function calls. Later when I needed additional set up, I used the same complex editor command to accomplish the task.
It occurred to me that what I was doing was taking unreadable complexity out of code where I, let alone someone else, couldn’t remember or read what was going on, and i was moving it into my tools. My tools I use every day so I remember how to manage the complexity and I’m not condemning others to learn the complexity when I put it there. I think this makes a simple guideline for balancing DRY with readability. Some complexity belongs in your tool usage, not in the code.
Updated on 25 November 2008
Imported from Plone on Mar 15, 2021. The date for this update is the last modified date in Plone.
Comments
comments powered by Disqus