Don’t write CRISP, write PERFECT.
Plain, exciting, refreshable, fast, entertaining, code (with) tabs.
Don't write clean code, write CRISP code
91–100 of 170 posts
Re: Don't write clean code, write CRISP code
#92DRY 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.
True, but then you also get times when somebody who should know better implements a "in current financial year w/ special cases" function 3 times.
Then your tester says it isn't correct in 2/3 places, you find out you've only updated the function in 1 place and either abstract those the other 2 cases out or update it in those 2 places aswell.
Re: Don't write clean code, write CRISP code
#93Re: Don't write clean code, write CRISP code
#94Earlier quoted context omitted.
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
Don't miss the opportunity to add in some of those fancy SIMD instructions as well somehow!
Re: Don't write clean code, write CRISP code
#95Earlier quoted context omitted.
I prefer calling it WET (We Enjoy Typing)
These days Copilot tremendously helps me with those kinds of repetitive code.
This is my experience as well. GitHub Copilot has been very efficient at generating variants of boiler plate code. It allows you to efficiently repeat code so you can delay code abstraction or generalisations until you are confident a generalisation makes sense.
Having worked as a developer for many years I now much prefer to repeat code a bit to making the wrong abstractions to early. The tedium of writing out code is now reduced thanks to well performing language models.
Re: Don't write clean code, write CRISP code
#96I like John. What I don't like is dogma. There's a lot in HR. Also hype.
Re: Don't write clean code, write CRISP code
#97DRY 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.
Seems whenever someone popularizes a rule of thumb, expressed in a catchy way, some newbies will take it as inviolable absolute law that everything else must be bent around, at any cost.
Re: Don't write clean code, write CRISP code
#98DRY 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.
My take is that all this WET/DRY wisdom makes people think about abstractions in the wrong way -- it makes us debate them in term of when, rather than what and why.
In my mind, the point of abstraction is to transform models such that we can build solutions in a way that is a better fit for the problems at hand. Reducing LOC and repetition is explicitly not the goal, sometimes a good abstraction may actually result in more lines of code (but more often it's less). So reducing LOC and repetition is commonly a happy byproduct, rather the reason we do it in the first place.
I see slightly more experienced programmers rebound from DRY to a point of having a pathological distaste for abstractions, and I find those codebases to be far more stressful to work in than ones which just happen to have a few bad abstractions.
Re: Don't write clean code, write CRISP code
#99DRY 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 put it second behind "premature optimisation" which is used to justify never caring about performance at all (until it's too late and you can't do anything about it).
Actual premature optimisation is harmful for the same reason as premature abstraction. In both cases, improvements that come "for free" should be done without thinking, but one they start to impact readability, we should consider how beneficial those changes really are.
Re: Don't write clean code, write CRISP code
#100DRY 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 me DRY is one of the most important principles for maintainable software. Imagine having to fix a bug at two independent places or having to add or change the same conceptual functionality at two different places (which you may not even be aware, because you don't remember you copied code somewhere else once)
Totally unnecessary bugs guaranteed, and ready to be thrown away after some time, because a change will be harder than a rewrite.
It's enough pain when the effort is too big to avoid (e.g. Js frontend, Rust Backend) it.
Juniors will learn the difference between actual and imagined similarities at some time.