14 ms·

Don't write clean code, write CRISP code

157 points by bitfield 3y ago

booleandilemma 3y ago
Is this another acronym I'm going to have to learn for interviews?
ModestBee 3y ago
Introducing the new coding acronym, CHAOTIC! C - Confusing: Write code that is hard to understand, ensuring that only you can maintain it, thus securing your position in the company. H - Hodgepodge: Mix programming paradigms, libraries, and styles to create a unique blend of code that reflects your artistic side. A - Arbitrary: Make decisions about architecture, data structures, and algorithms without any specific reasoning, allowing for a more spontaneous and whimsical development process. O - Obfuscation: Deliberately make your code difficult to read and comprehend by using cryptic variable names, nested loops, and a lack of comments. 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 "bugs" that you secretly introduced. I - Inconsistent: Use different naming conventions, indentation styles, and language features throughout your code to keep things interesting and unpredictable. 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. 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!
adamors 3y ago
Uh, another acronym to be tortured by in interviews.
- BulgarianIdiot 3y ago
  Yeah, I cringed and I think I chipped a tooth just by reading the headline. I'm so sick of these "let me sell you a book & some consultation" BS constructs.
  - tgv 3y ago
    The first take-away of the article is: > Anyone who has a foolproof software engineering methodology to sell you is a charlatan, especially if the methodology has a neat backronym. Some of the others (there's more take-away than content, perhaps) are also note-worthy, except that I don't believe in correctness. Some functions may be well tested, but most be assumed partially faulty. It just isn't feasible to make them all correct. The article is jumping between these two stances, so this is not a great take-away.
awestroke 3y ago
Americans love their acronyms. I don't foresee this one catching on
- sh4rks 3y ago
  Maybe CHIP would suit the Americans better
  - sgt 3y ago
    That'll work too. Correct Human-readable Idiomatic Performant
  - ElfinTrousers 3y ago
    I hesitate to speak for every American but I think FRY would go over better.
BulgarianIdiot 3y ago
What CRISP is supposed to mean: Correct Readable Idiomatic Simple Performant Notice that all this is just well-wishing and suitably vague, so that you feel the need to buy a book & hire a consultant to explain it to you. The trick is there's nothing to explain.
- MoreQARespect 3y ago
  This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measurable.
  - vbezhenar 3y ago
    There are plenty of code metrics. I'm not aware of any that I would recommend, though (other than basic ones like keep function LoC <= 50, keep indentation level <= 3). But if you're interested, you can research this topic. I saw tools for Java which measure those code metrics.
  - BulgarianIdiot 3y ago
    The only objective rule in SOLID is L: "Objects of a superclass should be replaceable with objects of its subclasses without breaking the application." And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X. The other rules are so vague and subjective, that you can spin them any way around to prove someone's code sucks if you choose so. Which is ideal for selling people books & consultation services. And for Internet arguments.
    - mejutoco 3y ago
      When possible, I prefer to do away with objects and have functions with types. X in, Y out.
      - diarrhea 3y ago
        A style I like as well, but methods are exactly that as well, only that `X` is implied, and there's a danger of abusing state (`f(X) -> Y` can and often is pure, whereas the entire point of methods is to be impure (modifying instance state)).
KyeRussell 3y ago
So, which of these criteria were contrived, and which were left out, all to make this fit into “CRISP”?
- quickthrower2 3y ago
  SOLID
BulgarianIdiot 3y ago
Well, since we're in a fancy acronym thread, here are some for your attention: Beneath Utterly Ludicrous Labels, Salespeople Hawk Ineffective Tricks. Bogus Utterances (with) Little Legitimacy, Sold (to) Helpless IT Teams. Business Units Love Lingo, Selling Hyped IT Truisms. Credit: ChatGPT.
edumucelli 3y ago
It is laughable talk about "Don't Repeat Yourself principle" 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 "DRY" ... That is everything but "simple" as described in the article.
- josephg 3y ago
  > Before that you had to write a for loop every time you wanted something from an array. How often do you do that? I mean, it comes up - but if you're linearly scanning every time you want to select something from a list, that sounds like a surefire way to write slow code to me. Is there a reason you aren't using a map?
  - tsimionescu 3y ago
    Linearly scanning a small array is very likely to be faster than looking up a key in a map. Especially if we factor in memory cost and not just speed.
    - akasakahakada 3y ago
      Now I understand why mordern web is slow as hell.
      - tsimionescu 3y ago
        Then you probably misunderstand just how much work a CPU can actually do in the time it takes to read a new cache line from main memory.
        akasakahakada 3y ago
        Now you miss the point that you need to read that list from RAM in order to do for loop too.
themodelplumber 3y ago
I like to read these kinds of prospective acronyms, because sometimes they provide new perspectives or leverage points that other, existing acronyms don't. And they are easier to remember than, say, an essay. 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 "oh my god, I'm not really DRY but I totally could be" so it was really neat to discover. In the case of CRISP, the "Correct" criterion somehow seems far less tractable to me than the other terms, and even less tractable than "Clean" for some reason. To me it reads like a hint at subjective, self-contained logic. That's great, insofar it's instrumental to how code either works or doesn't. But "Correct" is also kind of getting negative connotations these days, for a lot of reasons. (Imagine also, receiving "your code could be more DRY" feedback, vs. "your code could be more CRISP," wherein you look up the latter and think, "oh right, my code could be more _correct_!") And then the author even takes the argument in the ad-infinitum direction by referring to e.g. what _else_ isn't correct here? My tests? My purpose? My gut biome? (Ok not the last one). But there's a reason why Correctness is a thing in science, and a big part of that is scope constraint. Maybe "Cogent" 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. I would also guess that a word like "Contractual" or "Compliant" would provide more leverage toward the same outcome. But those are already used around code in other ways, I guess... Anyway, it's interesting to think about, because these little acronyms can really help when applied, if they reveal some traction that's been missing. (This also made me wonder...why is one of the world's most popular crispy rice chocolate bars called a Crunch bar, and not a CRISP bar. Hmm)
- Bjartr 3y ago
  > how code either works or doesn't. That's all "correct" is trying to mean here. As a synonym for "working". Can you share a bit more on the negative connotations of "correct"? Nothing comes to mind for me.
  - themodelplumber 3y ago
    That's all? Good argument for RISP then. I have to ask, what's the point of telling coders--presumably experienced ones if they are familiar with the concept of clean code--to try to get their code to work? "Have you tried getting it working?" (I really think the author must mean more than that, given the segue into testing one's tests? Why do that, if the thing is working? Or does one assume at all times, forever, that it's broken? That's not really mentioned) So IMO the energy that goes into justifying the word probably isn't worth the carnival ride to the exciting world of status quo, so to speak. "Correct" as a word has also had quite a social shadow side ever since Political Correctness became a thing at the very least. What it amounts to is de facto social resistance to the topic of whether one's creation is correct. These days it's even more encumbered by the ongoing reconciliation dialog regarding "incorrect or just different?" E.g. divergence from pack or narrative in various ways being not so bad a thing by default anymore, especially insofar as the resulting support structure makes new room for new ideas that move past the worst parts of who we all used to be. But that's just one aspect; telling a coder to check that their code is correct is also an awkward way to communicate on its face, especially if that's the first answer to "how can this model help me to be a better coder" for example. It's going to drop the author into literal mansplain territory for huge swaths of audience. It's like first principles, for people who don't know what code is meant to accomplish. Just some ideas though. So, where's the value of having this word in there? Does the model really need the word at all? If so, why?
edu 3y ago
Code should be CODE: "Clean, Optimized, Documented, Efficient".
- naijaboiler 3y ago
  Just curious. How is optimized different from efficient
  - awestroke 3y ago
    It's a bad word choice, but fitting it into an acronym is more important than giving good advice
  - hkwerf 3y ago
    Probably he was just fishing for adjectives, but generally, optimization just just the minimization of any function. Efficiency could be the minimization of a function describing resource usage. In the real world, in real time systems one often optimizes for low jitter, which is often not contradictory to optimizing for efficiency, as one may reserve resources to keep them available in order to process requests faster, even though they're not required.
clnq 3y ago
Since we’re adding new backronyms every day, I propose SIMPLE. S - Spaghetti: write tapestry of code like a chef. I - Interlinked: if the project has modules, they should all depend on each other (we are strongest when we can depend on one another). M - Micromanaged: if the product owner doesn’t expect reports in the daily stand-up, do they even care? P - Perplex: diversity for the codebase. 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. 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.
- MrGilbert 3y ago
  I‘d like to extend it to SIMPLED: D - Duplicated: it's always good to have backup code at hand.
  - arethuza 3y ago
    I'd go with SSIMPLEDD - because it needs to Scale and more Duplication must be better?
    - MrGilbert 3y ago
      Great! Let me propose SSIIMPLEDD: I - Iteration: As we showed over the last 2 hours, iteration is always the way to go.
      - arethuza 3y ago
        All you need to do is get Y in there and we'd have recursion covered as well.
        dathinab 3y ago
        SSIIMPLEDD + Y + keeping redundancy apart to avoid merge conflicts + spaces for readability SIMP DED SILY
urig 3y ago
Don'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've generally described and grouped together into a catchy acronym. Yay me! * - Granted the book was written by an asshole.
- fredrikholm 3y ago
  Could you elaborate on the last point?
  - riffraff 3y ago
    Uncle Bob has been widely criticized for his political stances, basically being a MAGA republican. This also spilled into some critiques of Clean Code which are sometimes colored by this.
    - rTX5CMRXIfFG 3y ago
      Eh, I don’t even know anything about his politics but I read his Clean Architecture and I saw immediately what a hot pile of garbage it is. The book is full of platitudes, the author is so conceited that he cites his other works to justify his statements, and he’s far more concerned about being immortalized or revered in the industry for his coinages of principles, than by coming up with a mechanistic model of what makes a good computer program and ways of measuring that quality.
      - riffraff 3y ago
        Sure, but being a bad programmer does not make you an "asshole", which is what the original commenter asked about.
    - dagw 3y ago
      Uncle Bob has been widely criticized for his political stances, basically being a MAGA republican. I don't think that's a fair representation of his critics. I've been reading (and even occasionally writing) critiques of Uncle Bob for many years, and you are literally the first person I've ever seen even mentioning is political stance. Up until 30 seconds ago I'd not once reflected over who Uncle Bob might vote for.
moralestapia 3y ago
Ok. * starts writing CRISP code *
nextlevelwizard 3y ago
If you could just write good code that would be fine.
throwaway5371 3y ago
i just try to write code that can be deleted later the sooner the better
jiggywiggy 3y ago
Very often it's the design pattern people that make code unreadable.
- another2another 3y ago
  There's a good phrase to use in code reviews... "This code is Design Pattern unreadable. Please redo simpler."
- mekoka 3y ago
  So true. Sometimes, you read some source and you think "surely, there was a simpler way to implement whatever this is". Then you notice that the class name ends with "Visitor". Mystery solved. Now go make yourself a coffee, a pattern has been deployed.
waltertamboer 3y ago
"The problem, of course, is that few of us can agree on what "clean code" means, and how to get there. A rule like "methods should only do one thing" looks great on a T-shirt, but it's not so easy to apply in practice. What counts as "one thing"? I don't agree with this statement at all. From my experience this is perfectly possible. Maybe I'm misunderstanding the statement... why would it be hard to write methods that only do one thing?
- konschubert 3y ago
  “One thing” can mean different things depending on the level of abstraction. If you don’t understand that, I can understand how the rule could seem confusing
- themodelplumber 3y ago
  It seems like the author could be looking at your method at the statement level, for example. What does that if/else do? One thing or two? What does this say about the method? But as I commented elsewhere, there's not a lot of attention to topical scope in the article either, so it also sets out to do the metaphorical "one thing", and then somehow merges with the broader philosophical world...
- deleted 3y ago
  [deleted]
- gizmo 3y ago
  Because it's an artificial constraint that makes code worse. You end up with a whole bunch of functions that have only a single call-site and half a dozen parameters that don't make much sense. If you can only understand what a function does by looking at the call site then the function is no longer a self-contained piece of functionality and it shouldn't exist. When you write very simple code you can have short functions that do one thing. When you work on more complex projects some functions will just be 300 lines long and breaking them up will just make the code harder to understand and harder to work with. Take sqlite for instance: https://github.com/smparkes/sqlite/blob/master/src/vdbeaux.c https://github.com/smparkes/sqlite/blob/master/src/vdbeaux.c You'll find plenty of cases where functions do multiple things in sequence and those functions are long-ish because of it, and some "clean code" type programmers would feel compelled to refactor the code and make it way worse.
omeid2 3y ago
I can't stand the insistence on "idiomatic". Taken to extreme it is essentially gate-keeping and dogma: "We have always done it so."
- stuartd 3y ago
  Ah but idioms change as languages evolve. To me idiomatic is ‘the way it’s done now’ rather than ‘the way it’s always been done’
- unwind 3y ago
  I think is has value for code to be idiomatic. It's a very dynamic goal post for sure, which is a problem in a rule but not in a principle like in the article. To me, code that is not idiomatic sounds wrong, which is at least a cognitive hurdle (you need to spend more thinking power to unravel/decode it to figure out the meaning). I believe this is in line with the usage regarding natural (human) languages. A sentence might be syntactically correct but if its non-idiomatic it sounds wrong and throws the listener(s) for a loop understanding it. A very simple example is that in C, I greatly favor allocations to be written according to: P = malloc(N * sizeof *P) where P is the pointer variable receiving the return value, and N is an expression yielding the number of desired elements. The sizeof is completely idiomatic, always present unless I'm allocating an actual byte buffer, and always de-references P like that to lock the size to the receiving pointer. So this is my idiom for how an allocation is written. It might (should!) be yours, too but that's not a requirement in a personal principle I guess.
dkdbejwi383 3y ago
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.
- physicles 3y ago
  For best results, set your DRY dial to 8 or 9 out of 10. Settings higher than 9 result in premature or excessive abstraction. But if you hate DRY so much, imagine a word where people set it to 1 or 2. I wouldn’t want to work in that code base.
  - swader999 3y ago
    Whatever you do, never turn it up to 11,
    - zambal 3y ago
      But what if you just need that extra bit of dryness and you're already at 10?
  - fendy3002 3y ago
    heck, sometimes even 7 is better than 9
    - postalrat 3y ago
      Often the best way to DRY something if to let it sit in the sun a while where everyone can see it.
- m_mueller 3y ago
  Totally agreed. I've tried explain exactly this issue in a talk [1], trying to find a useful synthesis between different paradigms like KISS, DRY and YAGNI. [1] https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsIG11ZWxsZXIga2lzcyBkcnk%3D https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsI...
djvu97 3y ago
> Who wants to write dirty code, unless maybe it's for a porn site? Even porn sites need to write great code to handle huge traffic. I am offended by this
- gjm11 3y ago
  If that's meant seriously rather than as a joke: I think you're misunderstanding. They aren't saying "porn sites don't care about code quality", they're making a pun on the word "dirty".
- themodelplumber 3y ago
  It's a bit of an awkward protrusion to thrust into an article that's aimed at general tech audiences. And I did wonder, reading that: IS there actually a dirty coding language for porn sites? Certainly the simplest of erections in that area could arouse some latent skill. Contributions would likely be furious. Though some annoying friction is perhaps practically guaranteed, depending on which executive discovers, in which way, which particular feature set of their corporate software project was conceived...
  - animuchan 3y ago
    Now I want to create this language, thanks!
    - themodelplumber 3y ago
      Would love to see it. May my freshly earned downvotes be good for something, this is the world I like to be a part of. It's interesting how people love to hate on plain old passion, with passion...this is quite an irrational kink really, tho the bar isn't generally set very high
- h4ch1 3y ago
  I did a stint for a website y'all know very well and believe me, the amount of optimizations we had to do were on par with Netflix. That codebase was much more well organized and sane than any Fortune 500 project I've seen in a long time. Some days I used to wonder if I could get a book deal off of this but that's thinking too big xd.
atoav 3y ago
Don't write crisp code write deep fried code.
Manjuuu 3y ago
The "simple" 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.
Alex3917 3y ago
> So, while readability isn't quite as important as correctness, it's more important than anything else. 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't necessarily easy to back and make it more readable.
BaculumMeumEst 3y ago
you are not going to solve the problem that the meaning of "clean code" is vague and subjective by introducing a new set of terminology that is also vague and subjective
anti_con_men 3y ago
Don't write XYZ code, write code that works and that you can maintain.
dgellow 3y ago
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! 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++.
nuancebydefault 3y ago
In fact there only a few things that matter: - code, when executed, should do what is expected. - code should be maintainable. All the rest are just some ways to get there, but not must-haves. One great way to get there is: - discuss architecture, nomenclature and design choices. Document those. - have your code and docs reviewed and discuss/rework accordingly. The above in a rinse and repeat manner.
eternityforest 3y ago
Completely agree, except that simplicity is kind of redundant. If the code is correct and readable, I don't see why I need to simplify it any further, to me it's probably simple enough if the complexity isn'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'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. I'd much rather have DRY than simplicity, because repetition creates the possibility for later divergence and incompatibility and stuff left behind. What if there's a bug in the thing you repeated and only 9 out of 10 get fixed because of an oversight?
akasakahakada 3y ago
> 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 what's wrong with this false assumption?
- another2another 3y ago
  Death by 100 poorly chosen algorithms?
suralind 3y ago
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'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's API), you may be just fine logging to some buffer instead of maintaining mocks (and in Go you'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).
dathinab 3y ago
S - Simple Is never simple as people can just not at all agree on what simple means. Even experienced programmers. This isn't even a question of training. It's deeply embedded into human nature due to peoples thought process differing and in turn what they find simple. P - Performant 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 "better" code can sometimes be a very good decision. Somewhat derived from "simplicity" and readability but not any less important is making code easy to change (by literally changing it, not by making it configurable or parametrized). The problem with DRY and similar isn't that it'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. For example DRY is about not repeating "business logic" (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/genericity often using means which make the code again harder to change. I.e. TL;DR: DRY isn't bad but like most things it's not a rule you can blindly apply but a tool/skill you need to learn to properly use, including when to not use it. (1): What counts as "business logic" differs depending on the abstraction level/context you are looking at the code; That doesn't make it easier to use.
- zamnos 3y ago
  DRY is so that when you change one place, you don't forget to change it in the other place, likely resulting in a bug or bugs. There is a simple (for some people's definition of simple) solution to this, which is to document this dependency in a comment in all four places - the extra two being the end of the particular block as well, so it doesn't get missed by a reviewer if the starting comment is past the top of the screen for the reviewer. Having this checked by your automated testing system is left as an exercise for the reader.
chillbill 3y ago
Don’t write CRISP, write PERFECT. Plain, exciting, refreshable, fast, entertaining, code (with) tabs.
lakomen 3y ago
I like John. What I don't like is dogma. There's a lot in HR. Also hype.
ElfinTrousers 3y ago
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!
highfrequency 3y ago
Make it work, make it simple to understand for people with no context, make it robust to edge cases and bad inputs.
Derbasti 3y ago
This article was way too long for what it said. Not very crisp, one might say.
mawadev 3y ago
I'm feeling more crunchy today, I will try crisp coding tomorrow
gregfjohnson 3y ago
This essay is great. Regarding simplicity, a couple of amusing observations: "I apologize for such a long letter - I didn't have time to write a short one." - Mark Twain (a variation of the French original by Blaise Pascal) Similarly for writing software: First, get it right. Then, as with writing in general, rewrite ruthlessly until it is clean, beautiful, and simple. Simplicity might be "defined" the way Justice Stewart (non-)defined pornography: "I can't give you a definition of it, but I know it when I see it." 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. 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, "WTF is going on here?" Can we rename that method or class or file to give the reader a clue? It also reminds me of Paul Erdos' idea of "The Book", where God keeps all of the simplest and most beautiful proofs. As Erdos said, "You don't need to believe in God, but you should definitely believe in The Book!" His (and Selberg's) elementary proof of the prime number theorem, developed 60 years after the original proof, would be a great example of this.
- icermann 3y ago
  Reminds me of the quote by Kent Beck (allegedly): "Make it work. Make it right. Make it fast". First throw something together that works, then refactor it to make it "right" (clean, readable etc). Finally optimize it if it's necessary. Like the author of this article describes it "Write more bad code. [..] Get answers. Learn as much as you can about the problem you’re trying to solve [..] it’s much faster in the long term to write bad code then make it good, than to try to write good code in the first place" https://medium.com/swlh/coding-faster-make-it-work-then-make-it-good-6aa988ebd8ab https://medium.com/swlh/coding-faster-make-it-work-then-make...
mekoka 3y ago
A summary. Correctness: the primary objective. Code that does what it's supposed to, bug free. 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. Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already. Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious. Performant: be aware of RAM (a bit of a letdown, was expecting "code to data structures" advice). --- Author concludes with a few interesting take-away points. Some highlights (paraphrasing): - don't trust foolproof software engineering methodologies sold using a neat backronym. - words like "clean", "simple", and "readable" are as vague as "freedom", "justice", or "equality". - neat slogan like "don't repeat yourself" or "clean code" are moot. - correctness above all else. - tests only prove that the code can pass the test. - No info is better than bad info. No tests is better than bad tests. - all software has two types of bugs: those you've found and those you have yet to find. - we all want readable code, but we have different definitions of "readability". ...
Warwolt 3y ago
Pretty decent article. People on this site fucking love getting riled up about stuff.
zokier 3y ago
Considering most software already fails on the first aspect, do the other four points really matter at all?
EVa5I7bHFq9mnYK 3y ago
Any manager would tell you, don't develop clean or CRISP, develop by the deadline.

157 points by bitfield 3y ago

Is this another acronym I'm going to have to learn for interviews?

Introducing the new coding acronym, CHAOTIC! C - Confusing: Write code that is hard to understand, ensuring that only you can maintain it, thus securing your position in the company. H - Hodgepodge: Mix programming paradigms, libraries, and styles to create a unique blend of code that reflects your artistic side. A - Arbitrary: Make decisions about architecture, data structures, and algorithms without any specific reasoning, allowing for a more spontaneous and whimsical development process. O - Obfuscation: Deliberately make your code difficult to read and comprehend by using cryptic variable names, nested loops, and a lack of comments. 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 "bugs" that you secretly introduced. I - Inconsistent: Use different naming conventions, indentation styles, and language features throughout your code to keep things interesting and unpredictable. 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. 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!

adamors 3y ago

Uh, another acronym to be tortured by in interviews.

BulgarianIdiot 3y ago
Yeah, I cringed and I think I chipped a tooth just by reading the headline. I'm so sick of these "let me sell you a book & some consultation" BS constructs.
- tgv 3y ago
  The first take-away of the article is: > Anyone who has a foolproof software engineering methodology to sell you is a charlatan, especially if the methodology has a neat backronym. Some of the others (there's more take-away than content, perhaps) are also note-worthy, except that I don't believe in correctness. Some functions may be well tested, but most be assumed partially faulty. It just isn't feasible to make them all correct. The article is jumping between these two stances, so this is not a great take-away.

awestroke 3y ago

Americans love their acronyms. I don't foresee this one catching on

sh4rks 3y ago
Maybe CHIP would suit the Americans better
- sgt 3y ago
  That'll work too. Correct Human-readable Idiomatic Performant
- ElfinTrousers 3y ago
  I hesitate to speak for every American but I think FRY would go over better.

BulgarianIdiot 3y ago

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

MoreQARespect 3y ago
This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measurable.
- vbezhenar 3y ago
  There are plenty of code metrics. I'm not aware of any that I would recommend, though (other than basic ones like keep function LoC <= 50, keep indentation level <= 3). But if you're interested, you can research this topic. I saw tools for Java which measure those code metrics.
- BulgarianIdiot 3y ago
  The only objective rule in SOLID is L: "Objects of a superclass should be replaceable with objects of its subclasses without breaking the application." And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X. The other rules are so vague and subjective, that you can spin them any way around to prove someone's code sucks if you choose so. Which is ideal for selling people books & consultation services. And for Internet arguments.
  - mejutoco 3y ago
    When possible, I prefer to do away with objects and have functions with types. X in, Y out.
    - diarrhea 3y ago
      A style I like as well, but methods are exactly that as well, only that `X` is implied, and there's a danger of abusing state (`f(X) -> Y` can and often is pure, whereas the entire point of methods is to be impure (modifying instance state)).

KyeRussell 3y ago

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

quickthrower2 3y ago
SOLID

BulgarianIdiot 3y ago

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

edumucelli 3y ago

It is laughable talk about "Don't Repeat Yourself principle" 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 "DRY" ... That is everything but "simple" as described in the article.

josephg 3y ago
> Before that you had to write a for loop every time you wanted something from an array. How often do you do that? I mean, it comes up - but if you're linearly scanning every time you want to select something from a list, that sounds like a surefire way to write slow code to me. Is there a reason you aren't using a map?
- tsimionescu 3y ago
  Linearly scanning a small array is very likely to be faster than looking up a key in a map. Especially if we factor in memory cost and not just speed.
  - akasakahakada 3y ago
    Now I understand why mordern web is slow as hell.
    - tsimionescu 3y ago
      Then you probably misunderstand just how much work a CPU can actually do in the time it takes to read a new cache line from main memory.
      - akasakahakada 3y ago
        Now you miss the point that you need to read that list from RAM in order to do for loop too.

themodelplumber 3y ago

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

Bjartr 3y ago
> how code either works or doesn't. That's all "correct" is trying to mean here. As a synonym for "working". Can you share a bit more on the negative connotations of "correct"? Nothing comes to mind for me.
- themodelplumber 3y ago
  That's all? Good argument for RISP then. I have to ask, what's the point of telling coders--presumably experienced ones if they are familiar with the concept of clean code--to try to get their code to work? "Have you tried getting it working?" (I really think the author must mean more than that, given the segue into testing one's tests? Why do that, if the thing is working? Or does one assume at all times, forever, that it's broken? That's not really mentioned) So IMO the energy that goes into justifying the word probably isn't worth the carnival ride to the exciting world of status quo, so to speak. "Correct" as a word has also had quite a social shadow side ever since Political Correctness became a thing at the very least. What it amounts to is de facto social resistance to the topic of whether one's creation is correct. These days it's even more encumbered by the ongoing reconciliation dialog regarding "incorrect or just different?" E.g. divergence from pack or narrative in various ways being not so bad a thing by default anymore, especially insofar as the resulting support structure makes new room for new ideas that move past the worst parts of who we all used to be. But that's just one aspect; telling a coder to check that their code is correct is also an awkward way to communicate on its face, especially if that's the first answer to "how can this model help me to be a better coder" for example. It's going to drop the author into literal mansplain territory for huge swaths of audience. It's like first principles, for people who don't know what code is meant to accomplish. Just some ideas though. So, where's the value of having this word in there? Does the model really need the word at all? If so, why?

edu 3y ago

Code should be CODE: "Clean, Optimized, Documented, Efficient".

naijaboiler 3y ago
Just curious. How is optimized different from efficient
- awestroke 3y ago
  It's a bad word choice, but fitting it into an acronym is more important than giving good advice
- hkwerf 3y ago
  Probably he was just fishing for adjectives, but generally, optimization just just the minimization of any function. Efficiency could be the minimization of a function describing resource usage. In the real world, in real time systems one often optimizes for low jitter, which is often not contradictory to optimizing for efficiency, as one may reserve resources to keep them available in order to process requests faster, even though they're not required.

clnq 3y ago

Since we’re adding new backronyms every day, I propose SIMPLE. S - Spaghetti: write tapestry of code like a chef. I - Interlinked: if the project has modules, they should all depend on each other (we are strongest when we can depend on one another). M - Micromanaged: if the product owner doesn’t expect reports in the daily stand-up, do they even care? P - Perplex: diversity for the codebase. 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. 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.

MrGilbert 3y ago
I‘d like to extend it to SIMPLED: D - Duplicated: it's always good to have backup code at hand.
- arethuza 3y ago
  I'd go with SSIMPLEDD - because it needs to Scale and more Duplication must be better?
  - MrGilbert 3y ago
    Great! Let me propose SSIIMPLEDD: I - Iteration: As we showed over the last 2 hours, iteration is always the way to go.
    - arethuza 3y ago
      All you need to do is get Y in there and we'd have recursion covered as well.
      - dathinab 3y ago
        SSIIMPLEDD + Y + keeping redundancy apart to avoid merge conflicts + spaces for readability SIMP DED SILY

urig 3y ago

Don'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've generally described and grouped together into a catchy acronym. Yay me! * - Granted the book was written by an asshole.

fredrikholm 3y ago
Could you elaborate on the last point?
- riffraff 3y ago
  Uncle Bob has been widely criticized for his political stances, basically being a MAGA republican. This also spilled into some critiques of Clean Code which are sometimes colored by this.
  - rTX5CMRXIfFG 3y ago
    Eh, I don’t even know anything about his politics but I read his Clean Architecture and I saw immediately what a hot pile of garbage it is. The book is full of platitudes, the author is so conceited that he cites his other works to justify his statements, and he’s far more concerned about being immortalized or revered in the industry for his coinages of principles, than by coming up with a mechanistic model of what makes a good computer program and ways of measuring that quality.
    - riffraff 3y ago
      Sure, but being a bad programmer does not make you an "asshole", which is what the original commenter asked about.
  - dagw 3y ago
    Uncle Bob has been widely criticized for his political stances, basically being a MAGA republican. I don't think that's a fair representation of his critics. I've been reading (and even occasionally writing) critiques of Uncle Bob for many years, and you are literally the first person I've ever seen even mentioning is political stance. Up until 30 seconds ago I'd not once reflected over who Uncle Bob might vote for.

moralestapia 3y ago

Ok. * starts writing CRISP code *

nextlevelwizard 3y ago

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

throwaway5371 3y ago

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

jiggywiggy 3y ago

Very often it's the design pattern people that make code unreadable.

another2another 3y ago
There's a good phrase to use in code reviews... "This code is Design Pattern unreadable. Please redo simpler."
mekoka 3y ago
So true. Sometimes, you read some source and you think "surely, there was a simpler way to implement whatever this is". Then you notice that the class name ends with "Visitor". Mystery solved. Now go make yourself a coffee, a pattern has been deployed.

waltertamboer 3y ago

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

konschubert 3y ago
“One thing” can mean different things depending on the level of abstraction. If you don’t understand that, I can understand how the rule could seem confusing
themodelplumber 3y ago
It seems like the author could be looking at your method at the statement level, for example. What does that if/else do? One thing or two? What does this say about the method? But as I commented elsewhere, there's not a lot of attention to topical scope in the article either, so it also sets out to do the metaphorical "one thing", and then somehow merges with the broader philosophical world...
deleted 3y ago
[deleted]
gizmo 3y ago
Because it's an artificial constraint that makes code worse. You end up with a whole bunch of functions that have only a single call-site and half a dozen parameters that don't make much sense. If you can only understand what a function does by looking at the call site then the function is no longer a self-contained piece of functionality and it shouldn't exist. When you write very simple code you can have short functions that do one thing. When you work on more complex projects some functions will just be 300 lines long and breaking them up will just make the code harder to understand and harder to work with. Take sqlite for instance: https://github.com/smparkes/sqlite/blob/master/src/vdbeaux.c https://github.com/smparkes/sqlite/blob/master/src/vdbeaux.c You'll find plenty of cases where functions do multiple things in sequence and those functions are long-ish because of it, and some "clean code" type programmers would feel compelled to refactor the code and make it way worse.

omeid2 3y ago

I can't stand the insistence on "idiomatic". Taken to extreme it is essentially gate-keeping and dogma: "We have always done it so."

stuartd 3y ago
Ah but idioms change as languages evolve. To me idiomatic is ‘the way it’s done now’ rather than ‘the way it’s always been done’
unwind 3y ago
I think is has value for code to be idiomatic. It's a very dynamic goal post for sure, which is a problem in a rule but not in a principle like in the article. To me, code that is not idiomatic sounds wrong, which is at least a cognitive hurdle (you need to spend more thinking power to unravel/decode it to figure out the meaning). I believe this is in line with the usage regarding natural (human) languages. A sentence might be syntactically correct but if its non-idiomatic it sounds wrong and throws the listener(s) for a loop understanding it. A very simple example is that in C, I greatly favor allocations to be written according to: P = malloc(N * sizeof *P) where P is the pointer variable receiving the return value, and N is an expression yielding the number of desired elements. The sizeof is completely idiomatic, always present unless I'm allocating an actual byte buffer, and always de-references P like that to lock the size to the receiving pointer. So this is my idiom for how an allocation is written. It might (should!) be yours, too but that's not a requirement in a personal principle I guess.

dkdbejwi383 3y ago

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.

physicles 3y ago
For best results, set your DRY dial to 8 or 9 out of 10. Settings higher than 9 result in premature or excessive abstraction. But if you hate DRY so much, imagine a word where people set it to 1 or 2. I wouldn’t want to work in that code base.
- swader999 3y ago
  Whatever you do, never turn it up to 11,
  - zambal 3y ago
    But what if you just need that extra bit of dryness and you're already at 10?
- fendy3002 3y ago
  heck, sometimes even 7 is better than 9
  - postalrat 3y ago
    Often the best way to DRY something if to let it sit in the sun a while where everyone can see it.
m_mueller 3y ago
Totally agreed. I've tried explain exactly this issue in a talk [1], trying to find a useful synthesis between different paradigms like KISS, DRY and YAGNI. [1] https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsIG11ZWxsZXIga2lzcyBkcnk%3D https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsI...

djvu97 3y ago

> Who wants to write dirty code, unless maybe it's for a porn site? Even porn sites need to write great code to handle huge traffic. I am offended by this

gjm11 3y ago
If that's meant seriously rather than as a joke: I think you're misunderstanding. They aren't saying "porn sites don't care about code quality", they're making a pun on the word "dirty".
themodelplumber 3y ago
It's a bit of an awkward protrusion to thrust into an article that's aimed at general tech audiences. And I did wonder, reading that: IS there actually a dirty coding language for porn sites? Certainly the simplest of erections in that area could arouse some latent skill. Contributions would likely be furious. Though some annoying friction is perhaps practically guaranteed, depending on which executive discovers, in which way, which particular feature set of their corporate software project was conceived...
- animuchan 3y ago
  Now I want to create this language, thanks!
  - themodelplumber 3y ago
    Would love to see it. May my freshly earned downvotes be good for something, this is the world I like to be a part of. It's interesting how people love to hate on plain old passion, with passion...this is quite an irrational kink really, tho the bar isn't generally set very high
h4ch1 3y ago
I did a stint for a website y'all know very well and believe me, the amount of optimizations we had to do were on par with Netflix. That codebase was much more well organized and sane than any Fortune 500 project I've seen in a long time. Some days I used to wonder if I could get a book deal off of this but that's thinking too big xd.

atoav 3y ago

Don't write crisp code write deep fried code.

Manjuuu 3y ago

The "simple" 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.

Alex3917 3y ago

> So, while readability isn't quite as important as correctness, it's more important than anything else. 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't necessarily easy to back and make it more readable.

BaculumMeumEst 3y ago

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

anti_con_men 3y ago

Don't write XYZ code, write code that works and that you can maintain.

dgellow 3y ago

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! 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++.

nuancebydefault 3y ago

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

eternityforest 3y ago

Completely agree, except that simplicity is kind of redundant. If the code is correct and readable, I don't see why I need to simplify it any further, to me it's probably simple enough if the complexity isn'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'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. I'd much rather have DRY than simplicity, because repetition creates the possibility for later divergence and incompatibility and stuff left behind. What if there's a bug in the thing you repeated and only 9 out of 10 get fixed because of an oversight?

akasakahakada 3y ago

> 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 what's wrong with this false assumption?

another2another 3y ago
Death by 100 poorly chosen algorithms?

suralind 3y ago

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'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's API), you may be just fine logging to some buffer instead of maintaining mocks (and in Go you'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).

dathinab 3y ago

S - Simple Is never simple as people can just not at all agree on what simple means. Even experienced programmers. This isn't even a question of training. It's deeply embedded into human nature due to peoples thought process differing and in turn what they find simple. P - Performant 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 "better" code can sometimes be a very good decision. Somewhat derived from "simplicity" and readability but not any less important is making code easy to change (by literally changing it, not by making it configurable or parametrized). The problem with DRY and similar isn't that it'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. For example DRY is about not repeating "business logic" (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/genericity often using means which make the code again harder to change. I.e. TL;DR: DRY isn't bad but like most things it's not a rule you can blindly apply but a tool/skill you need to learn to properly use, including when to not use it. (1): What counts as "business logic" differs depending on the abstraction level/context you are looking at the code; That doesn't make it easier to use.

zamnos 3y ago
DRY is so that when you change one place, you don't forget to change it in the other place, likely resulting in a bug or bugs. There is a simple (for some people's definition of simple) solution to this, which is to document this dependency in a comment in all four places - the extra two being the end of the particular block as well, so it doesn't get missed by a reviewer if the starting comment is past the top of the screen for the reviewer. Having this checked by your automated testing system is left as an exercise for the reader.

chillbill 3y ago

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

lakomen 3y ago

I like John. What I don't like is dogma. There's a lot in HR. Also hype.

ElfinTrousers 3y ago

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!

highfrequency 3y ago

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

Derbasti 3y ago

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

mawadev 3y ago

I'm feeling more crunchy today, I will try crisp coding tomorrow

gregfjohnson 3y ago

This essay is great. Regarding simplicity, a couple of amusing observations: "I apologize for such a long letter - I didn't have time to write a short one." - Mark Twain (a variation of the French original by Blaise Pascal) Similarly for writing software: First, get it right. Then, as with writing in general, rewrite ruthlessly until it is clean, beautiful, and simple. Simplicity might be "defined" the way Justice Stewart (non-)defined pornography: "I can't give you a definition of it, but I know it when I see it." 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. 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, "WTF is going on here?" Can we rename that method or class or file to give the reader a clue? It also reminds me of Paul Erdos' idea of "The Book", where God keeps all of the simplest and most beautiful proofs. As Erdos said, "You don't need to believe in God, but you should definitely believe in The Book!" His (and Selberg's) elementary proof of the prime number theorem, developed 60 years after the original proof, would be a great example of this.

icermann 3y ago
Reminds me of the quote by Kent Beck (allegedly): "Make it work. Make it right. Make it fast". First throw something together that works, then refactor it to make it "right" (clean, readable etc). Finally optimize it if it's necessary. Like the author of this article describes it "Write more bad code. [..] Get answers. Learn as much as you can about the problem you’re trying to solve [..] it’s much faster in the long term to write bad code then make it good, than to try to write good code in the first place" https://medium.com/swlh/coding-faster-make-it-work-then-make-it-good-6aa988ebd8ab https://medium.com/swlh/coding-faster-make-it-work-then-make...

mekoka 3y ago

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

Warwolt 3y ago

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

zokier 3y ago

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

EVa5I7bHFq9mnYK 3y ago

Any manager would tell you, don't develop clean or CRISP, develop by the deadline.