loading...
Cover image for Code Purity and Principles

Code Purity and Principles

erwald profile image Erich Grunewald ・3 min read

Code, like rooms, can be dirty. Mary Douglas wrote that dirt – the real, physical sort – is "matter out of place".1 You have an image of how you want your room to look, and all the stuff that doesn't fit that image, everything that's unwanted – that's dirt. And when you have rid your room of dirt, when it conforms to your image of how it should look, then it is clean, or pure. In this sense, cleaning is a creative act.

When you program, and especially when you refactor, you also have an image (though maybe not a conscious one) of how you want your program or procedure to look, and all the lines of code that don't fit that image are dirty. For instance, say you read about the single-responsibility principle – that each class or module or function should be responsible for one thing only. You read about it, it makes sense to you: it looks great. Now what? Every time you see a function that does two things, or a class that does a dozen things, it looks dirty to you. You want to change it so that it conforms to your image of clean code.

Douglas wrote that, in the human realm, a striving for purity has given rise to dietary rules, religious rituals, and social and sexual taboos. Many of those things seem strange to us now. But don’t we have equivalents in the world of programming? Well, yes, the parallel is pretty clear. We just call them "best practices", "habits" and "code smells" instead. But underneath it all it's the same striving for purity.

Now, you may be thinking that this is all irrational. Ancient dietary rules, magical rituals and cultural taboos are all things of the past! Like proverbs, they are crude, contradictory and based on feelings. We shouldn't let the yuck factor rule our lives. The appeal to emotion is a logical fallacy!

But these things are not irrational if we follow Jonathan Baron's definition of rational thinking: "[it] is whatever kind of thinking best helps people achieve their goals".2 Douglas interpreted these practices as existing not in order to maintain health or prevent disease, but an order. In the same way, best practices, good habits and avoidance of code smells, although they may be irrational in individual situations, on the whole work to keep the house of code in order.

General principles are better than nothing. But the moment you understand the deep reason a principle exists, the need for the principle vanishes. For instance, we hear that hardcoding configuration values is bad. Instead, you should parametrise. If you stick to this rule, you'll do all right. But if you understand why the rule exists – here, for reasons of extendability, reusability and portability – you already know when you ought to avoid hardcoded values, and you don't need to remember a rule that will misfire part of the time.

The principle of Chesterton's fence, generally stated, says that one shouldn't change something when one doesn't know how it came to be that way.3 Or, as the popular saying goes, you've got to learn the rules before you can break them. We can look at our best practices in that way. They have evolved over time and distil much of our best understanding about coding into a concise set of maxims. And as with any generalisation, they will miss the mark under some particular conditions. But for the most part they help us achieve our goals.4

Schopenhauer described pedantry as what happens when people "lack confidence in their own understanding" and, instead of thinking for themselves, with an eye to the particular, "start out from universal concepts, rules and maxims and seek to hold themselves exactingly to these".5 Principles are like masons' scaffolding. We use them to learn, but when we have learned we have no need of them anymore, because the solid structure is there.


  1. Douglas, Mary. Purity and danger: an analysis of concept of pollution and taboo. London New York: Routledge, 2003. 

  2. Baron, Jonathan. Thinking and deciding. New York: Cambridge University Press, 2008. 

  3. Chesterton, G. K. The collected works of G.K. Chesterton. San Francisco: Ignatius Press, 1986. 

  4. DePonySum brings up one problem with Chesterton's fence. It sees change as something exogenous. So current best practices is something that just is over here, and somebody wanting to change them is coming from outside. Whereas, in practice, these conventions are constantly evolving, and it is only thanks to constant change and variation that they have improved and do continue to improve. 

  5. Schopenhauer, Arthur, et al. The world as will and representation. Cambridge New York: Cambridge University Press, 2010. 

Posted on by:

erwald profile

Erich Grunewald

@erwald

First-class second-rate coder.

Discussion

pic
Editor guide
 

Another way to think about it is like this.

To a beginner, poorly formatted code and well formatted code are equally hard to read, since the beginner has not learned to take advantage of the structure of the well formatted code.

This means that the beginner has no internal metric to understand what it means for code to be well formatted.

They must instead rely on an external metric, like a code style guide.

If they do not make the transition away from applying this external metric to applying an internal metric, they will be trapped in the pedantic application of that external metric.

And more than this, they will not be able to differentiate between pedantry and good judgment in others.

But as they benefit from good style, they will be lead naturally toward some kind of efficient style, and be able to exercise their own good judgment.

 

Wow. Simply wow. Amazingly interesting article.
And love the end, couldn't agree more.

Principles are like masons' scaffolding. We use them to learn, but when we have learned we have no need of them anymore, because the solid structure is there.

 
 

This article neatly summarised some of the concepts am thinking of and reading about recently. It's always nice to see different mental models applied to programming. Am so glad you provided the links. I am going to deep dive into each one of them and learn more.

Couple of talks which helped me form some mental models in the recent times.

Sarah Mei, talks about code as living spaces. She explains, like living spaces, code bases also over time with small ignorances and inactions, here and there, leads to what we call an unmaintainable legacy codebase. Rewriting the entire project won't help with out change in the behaviour of the team and their communication. She did a fantastic job in her talk liveable code

DHH has a talk where among other things, he talks about practices. He compares software practices like TDD to diet fads. We do things Just to show that we have the right intentions with out actually wanting to do the hard work or we are operating by the wrong metrics.

Would love to hear your views on these talks!