Don't write clean code, write CRISP code

Since we’re adding new backronyms every day, I propose SIMPLE.<p>S - Spaghetti: write tapestry of code like a chef.<p>I - Interlinked: if the project has modules, they should all depend on each other (we are strongest when we can depend on one another).<p>M - Micromanaged: if the product owner doesn’t expect reports in the daily stand-up, do they even care?<p>P - Perplex: diversity for the codebase.<p>L - Lazy: Bill Gates once said “I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it”, for example, without testing, collaborating with team members, or ensuring the feature works with anything else in the codebase.<p>E - Opinionated: because I believe E should stand for opinionated and everyone else will have to work around this with adapters. But E should mean Opinionated because Uncle Bab said so.

DRY is probably my least favourite programming meme. There are far too many overzealous juniors who learned it and have a bee in their bonnet about creating absurd abstractions around any two lines of code (or config) that have vague or imagined similarities, locking in all sorts of annoying indirection.

It is laughable talk about &quot;Don&#x27;t Repeat Yourself principle&quot; on a strongly biased towards Golang article. A language that took 13 years to add a simple method (Index) that helped the programmer to find an element in an array (slice). Before that you had to write a for loop every time you wanted something from an array. Talk about &quot;DRY&quot; ... That is everything but &quot;simple&quot; as described in the article.

A summary.<p>Correctness: the primary objective. Code that does what it&#x27;s supposed to, bug free.<p>Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote for clarity and be your own critic.<p>Idiomatic: Write code the way people in your community expect to read. Don&#x27;t surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already.<p>Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don&#x27;t DRY things up just for the sake of it. Don&#x27;t do too many things. Be parsimonious.<p>Performant: be aware of RAM (a bit of a letdown, was expecting &quot;code to data structures&quot; advice).<p>---<p>Author concludes with a few interesting take-away points. Some highlights (paraphrasing):<p>- don&#x27;t trust foolproof software engineering methodologies sold using a neat backronym.<p>- words like &quot;clean&quot;, &quot;simple&quot;, and &quot;readable&quot; are as vague as &quot;freedom&quot;, &quot;justice&quot;, or &quot;equality&quot;.<p>- neat slogan like &quot;don&#x27;t repeat yourself&quot; or &quot;clean code&quot; are moot.<p>- correctness above all else.<p>- tests only prove that the code can pass the test.<p>- <i>No info</i> is better than <i>bad info</i>. <i>No tests</i> is better than <i>bad tests</i>.<p>- all software has two types of bugs: those you&#x27;ve found and those you have yet to find.<p>- we all want readable code, but we have different definitions of &quot;readability&quot;.<p>...

This essay is great. Regarding simplicity, a couple of amusing observations: &quot;I apologize for such a long letter - I didn&#x27;t have time to write a short one.&quot; - Mark Twain (a variation of the French original by Blaise Pascal)<p>Similarly for writing software: First, get it right. Then, as with writing in general, rewrite ruthlessly until it is clean, beautiful, and simple.<p>Simplicity might be &quot;defined&quot; the way Justice Stewart (non-)defined pornography: &quot;I can&#x27;t give you a definition of it, but I know it when I see it.&quot;<p>There is the well-known programming experience of struggling with a crufty, complex piece of code. Then a new idea pops up, the code gets rewritten in a flash, and two thirds of it disappear. The result is obvious and inevitable.<p>Pair programming can really help here: As the author, you develop internal state that leads to a form of myopia about your code. A pairing partner can look at the code with fresh eyes and say, &quot;WTF is going on here?&quot; Can we rename that method or class or file to give the reader a clue?<p>It also reminds me of Paul Erdos&#x27; idea of &quot;The Book&quot;, where God keeps all of the simplest and most beautiful proofs. As Erdos said, &quot;You don&#x27;t need to believe in God, but you should definitely believe in The Book!&quot; His (and Selberg&#x27;s) elementary proof of the prime number theorem, developed 60 years after the original proof, would be a great example of this.

I like to read these kinds of prospective acronyms, because sometimes they provide new perspectives or leverage points that other, existing acronyms don&#x27;t. And they are easier to remember than, say, an essay.<p>DRY, for example, is instantly transferable to a bunch of other life practices and disciplines; people from dry cleaning to graphic design will hear about it and go &quot;oh my god, I&#x27;m not really DRY but I totally could be&quot; so it was really neat to discover.<p>In the case of CRISP, the &quot;Correct&quot; criterion somehow seems far less tractable to me than the other terms, and even less tractable than &quot;Clean&quot; for some reason.<p>To me it reads like a hint at subjective, self-contained logic. That&#x27;s great, insofar it&#x27;s instrumental to how code either works or doesn&#x27;t.<p>But &quot;Correct&quot; is also kind of getting negative connotations these days, for a lot of reasons.<p>(Imagine also, receiving &quot;your code could be more DRY&quot; feedback, vs. &quot;your code could be more CRISP,&quot; wherein you look up the latter and think, &quot;oh right, my code could be more _correct_!&quot;)<p>And then the author even takes the argument in the ad-infinitum direction by referring to e.g. what _else_ isn&#x27;t correct here? My tests? My purpose? My gut biome? (Ok not the last one). But there&#x27;s a reason why Correctness is a thing in science, and a big part of that is scope constraint.<p>Maybe &quot;Cogent&quot; is more fitting in such a case? It has less of an absolutist ring to it. It expresses a bar to measure up to, with more of a qualitative, less-checkboxy feel.<p>I would also guess that a word like &quot;Contractual&quot; or &quot;Compliant&quot; would provide more leverage toward the same outcome. But those are already used around code in other ways, I guess...<p>Anyway, it&#x27;s interesting to think about, because these little acronyms can really help when applied, if they reveal some traction that&#x27;s been missing.<p>(This also made me wonder...why is one of the world&#x27;s most popular crispy rice chocolate bars called a Crunch bar, and not a CRISP bar. Hmm)

&gt; Who wants to write dirty code, unless maybe it&#x27;s for a porn site?<p>Even porn sites need to write great code to handle huge traffic. I am offended by this

What CRISP is supposed to mean:<p>Correct<p>Readable<p>Idiomatic<p>Simple<p>Performant<p>Notice that all this is just well-wishing and suitably vague, so that you feel the need to buy a book &amp; hire a consultant to explain it to you. The trick is there&#x27;s nothing to explain.

Well, since we&#x27;re in a fancy acronym thread, here are some for your attention:<p>Beneath Utterly Ludicrous Labels, Salespeople Hawk Ineffective Tricks.<p>Bogus Utterances (with) Little Legitimacy, Sold (to) Helpless IT Teams.<p>Business Units Love Lingo, Selling Hyped IT Truisms.<p>Credit: ChatGPT.

Very often it&#x27;s the design pattern people that make code unreadable.

Introducing the new coding acronym, CHAOTIC!<p>C - Confusing: Write code that is hard to understand, ensuring that only you can maintain it, thus securing your position in the company.<p>H - Hodgepodge: Mix programming paradigms, libraries, and styles to create a unique blend of code that reflects your artistic side.<p>A - Arbitrary: Make decisions about architecture, data structures, and algorithms without any specific reasoning, allowing for a more spontaneous and whimsical development process.<p>O - Obfuscation: Deliberately make your code difficult to read and comprehend by using cryptic variable names, nested loops, and a lack of comments.<p>T - Tinkering: Constantly make small, undocumented changes to the codebase to keep your teammates on their toes and to give yourself an excuse to fix &quot;bugs&quot; that you secretly introduced.<p>I - Inconsistent: Use different naming conventions, indentation styles, and language features throughout your code to keep things interesting and unpredictable.<p>C - Cluttered: Avoid modularization and organization, and instead cram as much functionality into a single file as possible. This will create an exciting challenge for anyone attempting to decipher your masterpiece.<p>Embrace the CHAOTIC way and create a memorable, one-of-a-kind codebase that will leave a lasting impression on your colleagues and ensure your job security!

Uh, another acronym to be tortured by in interviews.

What an excellent post! What I would add though, is that you can gain some simplicity by removing abstractions (e.g. interfaces) and sometimes it&#x27;s just worth it. For example, a good practice may be to abstract away all implementations and use interfaces instead, but for things like logger (which may be a bit complex to abstract depending on it&#x27;s API), you may be just fine logging to some buffer instead of maintaining mocks (and in Go you&#x27;ll probably make expectations what they should be called with). Focus on things that matter - if you want to check logs in your tests too, make it as effortless as it can be (e.g. use snapshots for those).

Don’t write clean code, write the best way to express your idea without caring too much about how dirty that looks like, and let the AI chat bot rewrite it in the cleanest version that follows all the best practices!<p>I’m not even joking, that’s basically my process since ChatGPT-4 has been released :) That’s a dream for boilerplate heavy languages like Go, C#, and C++.

Completely agree, except that simplicity is kind of redundant. If the code is correct and readable, I don&#x27;t see why I need to simplify it any further, to me it&#x27;s probably simple enough if the complexity isn&#x27;t causing problems. It seems like engineers, and humans in general, really love simplicity for its own sake, in some deep way I that makes me wonder if I&#x27;m secretly a bad person, since it seems to so often be praised as connected to so many other virtues and most every philosopher ever seems to love it.<p>I&#x27;d much rather have DRY than simplicity, because repetition creates the possibility for later divergence and incompatibility and stuff left behind. What if there&#x27;s a bug in the thing you repeated and only 9 out of 10 get fixed because of an oversight?

In fact there only a few things that matter:<p>- code, when executed, should do what is expected.<p>- code should be maintainable.<p>All the rest are just some ways to get there, but not must-haves.<p>One great way to get there is:<p>- discuss architecture, nomenclature and design choices. Document those.<p>- have your code and docs reviewed and discuss&#x2F;rework accordingly.<p>The above in a rinse and repeat manner.

So, which of these criteria were contrived, and which were left out, all to make this fit into “CRISP”?

Don&#x27;t follow the concrete practices in the best-selling book* vetted by industry leaders for years, instead follow this set of 5 high level goals that I&#x27;ve generally described and grouped together into a catchy acronym. Yay me!<p>* - Granted the book was written by an asshole.

&gt; performance genuinely matters. Not as many as you might think, though: computers are pretty fast these days, and since most of what they do is in the service of us humans<p>what&#x27;s wrong with this false assumption?

Code should be CODE: &quot;Clean, Optimized, Documented, Efficient&quot;.

&quot;The problem, of course, is that few of us can agree on what &quot;clean code&quot; means, and how to get there. A rule like &quot;methods should only do one thing&quot; looks great on a T-shirt, but it&#x27;s not so easy to apply in practice. What counts as &quot;one thing&quot;?<p>I don&#x27;t agree with this statement at all. From my experience this is perfectly possible. Maybe I&#x27;m misunderstanding the statement... why would it be hard to write methods that only do one thing?

I can&#x27;t stand the insistence on &quot;idiomatic&quot;. Taken to extreme it is essentially gate-keeping and dogma: &quot;We have always done it so.&quot;

If you could just write good code that would be fine.

Make it work, make it simple to understand for people with no context, make it robust to edge cases and bad inputs.

Ok.<p><i>* starts writing CRISP code *</i>

Pretty decent article. People on this site fucking love getting riled up about stuff.

The &quot;simple&quot; part is so hard to understand even for people with high seniority. Once asking for simplicity I got back a mass of low effort code that seemed written out of spite, even if that was not the original intent.

I like John. What I don&#x27;t like is dogma. There&#x27;s a lot in HR. Also hype.

This article was way too long for what it said. Not very crisp, one might say.

Don&#x27;t write XYZ code, write code that works and that you can maintain.

Considering most software already fails on the first aspect, do the other four points really matter at all?

Any manager would tell you, don&#x27;t develop clean or CRISP, develop by the deadline.

&gt; So, while readability isn&#x27;t quite as important as correctness, it&#x27;s more important than anything else.<p>In most cases, readability is more important than correctness. If you have readable code, you can always make it work correctly later. But if you have code that merely works correctly, it isn&#x27;t necessarily easy to back and make it more readable.

Don’t write CRISP, write PERFECT.<p>Plain, exciting, refreshable, fast, entertaining, code (with) tabs.

Is this another acronym I&#x27;m going to have to learn for interviews?

I&#x27;m feeling more crunchy today, I will try crisp coding tomorrow

S - Simple<p>Is never simple as people can just not at all agree on what simple means. Even experienced programmers. This isn&#x27;t even a question of training. It&#x27;s deeply embedded into human nature due to peoples thought process differing and in turn what they find simple.<p>P - Performant<p>While a certain baseline performance does matter often (not always) anything beyond that yields increasingly diminishing returns. Discarding even large chunks of performance in rarely run non time critical code in favor of otherwise &quot;better&quot; code can sometimes be a very good decision.<p>Somewhat derived from &quot;simplicity&quot; and readability but not any less important is making code easy to change (by literally changing it, not by making it configurable or parametrized).<p>The problem with DRY and similar isn&#x27;t that it&#x27;s bad practice but that people take it too far and try to have rules they can just always blindly strictly always apply ignoring imperfections of e.g. other tools they use.<p>For example DRY is about not repeating &quot;business logic&quot; (1) but people try to forcefully apply it to language structure and things which just happen to be similar. They then often do so by using abstractions which make future changes to the code harder by put constraints on about what is possible. Another common failure is to not diverge (i.e. copy) you code when business logic diverges through a change of requirements but instead try to handle it by additional parameterizeation&#x2F;genericity often using means which make the code again harder to change.<p>I.e. TL;DR: DRY isn&#x27;t bad but like most things it&#x27;s not a rule you can blindly apply but a tool&#x2F;skill you need to learn to properly use, including when to not use it.<p>(1): What counts as &quot;business logic&quot; differs depending on the abstraction level&#x2F;context you are looking at the code; That doesn&#x27;t make it easier to use.

you are not going to solve the problem that the meaning of &quot;clean code&quot; is vague and subjective by introducing a new set of terminology that is also vague and subjective

Mind-blowing: I had been writing incorrect, unreadable, idiosyncratic, complicated, and slow code this whole time, thinking that was the thing to do. But now I see my mistake and will cease forthwith. Thanks, Captain Obvious!

Don&#x27;t write crisp code write <i>deep fried</i> code.

i just try to write code that can be deleted later<p>the sooner the better

Americans love their acronyms.<p>I don&#x27;t foresee this one catching on