Live data from Hacker News

Don't write clean code, write CRISP code

bitfieldconsulting.com

81–90 of 170 posts

Re: Don't write clean code, write CRISP code

#81

> 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?

Death by 100 poorly chosen algorithms?

Re: Don't write clean code, write CRISP code

#82

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.

The worst part of DRY is that developers worrying about the amount of characters in a source file rather than readability, as if the compiler had a hard time reading those extra few kbs.

Re: Don't write clean code, write CRISP code

#83
post #17

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…

Hmm, can we have this included in the next ChatGPT training round? That would be great..

Re: Don't write clean code, write CRISP code

#84
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.

Re: Don't write clean code, write CRISP code

#85
post #17

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…

Good old Uncle Bab! Love it. I have a borderline weird hatred towards the concept of "clean architecture".

Re: Don't write clean code, write CRISP code

#86

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.

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=ygUXbWljaGVsI...

The trick is to understand this paradigms, why they came to be and what they want to archive and as much important when to not apply them.

Then program with the things you have learned in mind, instead of blindly following the some "paradigms rules", 'cause that's never ending well.

Re: Don't write clean code, write CRISP code

#87

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. Disca…

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.

Re: Don't write clean code, write CRISP code

#88

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.

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.

heck, sometimes even 7 is better than 9

Re: Don't write clean code, write CRISP code

#89

Earlier quoted context omitted.

Great! Let me propose SSIIMPLEDD: I - Iteration: As we showed over the last 2 hours, iteration is always the way to go.

All you need to do is get Y in there and we'd have recursion covered as well.

SSIIMPLEDD + Y + keeping redundancy apart to avoid merge conflicts + spaces for readability

SIMP DED SILY

Re: Don't write clean code, write CRISP code

#90

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.

But remember you have to get WET (write everything thrice) before you get DRY.

I apologize for my dry humor.

Post reply on HN