> 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?
Don't write clean code, write CRISP code
81–90 of 170 posts
Re: Don't write clean code, write CRISP code
#82DRY 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.
Re: Don't write clean code, write CRISP code
#83Since 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…
Re: Don't write clean code, write CRISP code
#84Is 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
#85Since 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…
Re: Don't write clean code, write CRISP code
#86DRY 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...
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
#87S - 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…
Re: Don't write clean code, write CRISP code
#88DRY 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.
Re: Don't write clean code, write CRISP code
#89Earlier 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.
SIMP DED SILY
Re: Don't write clean code, write CRISP code
#90DRY 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.
I apologize for my dry humor.