Write code that is easy to delete, not easy to... — programming is terrible

“Every line of code is written without reason, maintained out of weakness, and deleted by chance” Jean-Paul Sartre’s Programming in ANSI C.

Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.<br>The more consumers of an API you have, the more code you must rewrite to introduce changes. Similarly, the more you rely on an third-party api, the more you suffer when it changes. Managing how the code fits together, or which parts depend on others, is a significant problem in large scale systems, and it gets harder as your project grows older.<br>My point today is that, if we wish to count lines of code, we should not regard them as &ldquo;lines produced&rdquo; but as &ldquo;lines spent&rdquo; EWD 1036

If we see &lsquo;lines of code&rsquo; as &lsquo;lines spent&rsquo;, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.<br>I don&rsquo;t need to tell you that deleting code is more fun than writing it.<br>To write code that&rsquo;s easy to delete: repeat yourself to avoid creating dependencies, but don&rsquo;t repeat yourself to manage them. Layer your code too: build simple-to-use APIs out of simpler-to-implement but clumsy-to-use parts. Split your code: isolate the hard-to-write and the likely-to-change parts from the rest of the code, and each other. Don&rsquo;t hard code every choice, and maybe allow changing a few at runtime. Don&rsquo;t try to do all of these things at the same time, and maybe don&rsquo;t write so much code in the first place.

Step 0: Don&rsquo;t write code<br>The number of lines of code doesn&rsquo;t tell us much on its own, but the magnitude does 50, 500 5,000, 10,000, 25,000, etc. A million line monolith is going to be more annoying than a ten thousand line one and significantly more time, money, and effort to replace.<br>Although the more code you have the harder it is to get rid of, saving one line of code saves absolutely nothing on its own.<br>Even so, the easiest code to delete is the code you avoided writing in the first place.

Step 1: Copy-paste code<br>Building reusable code is something that&rsquo;s easier to do in hindsight with a couple of examples of use in the code base, than foresight of ones you might want later. On the plus side, you&rsquo;re probably re-using a lot of code already by just using the file-system, why worry that much? A little redundancy is healthy.<br>It&rsquo;s good to copy-paste code a couple of times, rather than making a library function, just to get a handle on how it will be used. Once you make something a shared API, you make it harder to change.<br>The code that calls your function will rely on both the intentional and the unintentional behaviours of the implementation behind it. The programmers using your function will not rely on what you document, but what they observe.<br>It&rsquo;s simpler to delete the code inside a function than it is to delete a function.

Step 2: Don&rsquo;t copy paste code<br>When you&rsquo;ve copy and pasted something enough times, maybe it&rsquo;s time to pull it up to a function. This is the &ldquo;save me from my standard library&rdquo; stuff: the &ldquo;open a config file and give me a hash table&rdquo;, &ldquo;delete this directory&rdquo;. This includes functions without any state, or functions with a little bit of global knowledge like environment variables. The stuff that ends up in a file called &ldquo;util&rdquo;.<br>Aside: Make a util directory and keep different utilities in different files. A single util file will always grow until it is too big and yet too hard to split apart. Using a single util file is unhygienic.<br>The less specific the code is to your application or project, the easier they are to re-use and the less likely to change or be deleted. Library code like logging, or third party APIs, file handles, or processes. Other good examples of code you&rsquo;re not going to delete are lists, hash tables, and other collections. Not because they often have very simple interfaces, but because they don&rsquo;t grow in scope over time.<br>Instead of making code easy-to-delete, we are trying to keep the hard-to-delete parts as far away as possible from the easy-to-delete parts.

Step 3: Write more boilerplate<br>Despite writing libraries to avoid copy pasting, we often end up writing a lot more code through copy paste to use them, but we give it a different name: boilerplate. Boiler plate is a lot like copy-pasting, but you change some of the code in a different place each time, rather than the same bit over and over.<br>Like with copy paste, we are duplicating parts of code to avoid introducing dependencies, gain flexibility, and pay for it in verbosity.<br>Libraries that require boilerplate are often...