Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't write clean code, write CRISP code

bitfieldconsulting.com

Post reply on HN
Print view View original

121–130 of 170 posts

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

#121

Post by h4ch1 »

djvu97 wrote: post #39

> 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

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.

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

#122

Post by whstl »

gizmo wrote: post #41
waltertamboer wrote: post #31

"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 th…

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 func…

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

Wow, this is a solid guideline. Alright perhaps "SOLID" isn't the best adjective to use, but it's great advice :)

I find this in line with John Ousterhout's "Philosophy of Software Design", where there's a guideline saying that modules (classes/functions/components/etc) should be deep and interfaces simple. Instead of dividing methods/classes due to their size in lines, you should be dividing where interfaces can be simpler. Because a complex interface imposes a lot of complexity in the consumers of the module.

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

#123

Post by lolinder »

dkdbejwi383 wrote: post #37

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.

Yes, that happens, but I've also had to take over a large iOS app written by a self-taught programmer who never learned DRY. They didn't factor out any shared code whatsoever. Any time they needed to do something that had already been done, they just bounced over to the other controller and copied the code over.

Of course, the copied code was often buggy, and they would only fix the instance in the controller where the bug was reported. When bugs were fixed it was pretty much random chance which version would be chosen to copy when needed again, so creating the right abstractions involved piecing together an entire phylogenetic tree of the code to decide which pieces were supposed to be the same and which were legitimately different.

Add a commit history that looked like "v1", "v2", "v3", and... yeah. We finally decided it would be cheaper to scrap the app and rewrite it from scratch.

So, yes, premature abstraction is a huge problem, but so is the opposite extreme, and after that experience I personally would choose overly-indirect code over the mess I inherited. It's easier to untangle a function that has too many callers than it is to find code that should have been shared after months of divergent evolution.

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

#124

Post by MoreQARespect »

tcfhgj wrote: post #100
dkdbejwi383 wrote: post #37

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 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 b…

It is fundamental but it's in constant tension with other principles - e.g. cohesion and coupling.

I'm pretty sure all of the most fundamental principles of good code are in tension with each other.

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

#125

Post by stuckinhell »

clnq wrote: 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…

I laughed.

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

#126

Post by mejutoco »

diarrhea wrote: post #119
mejutoco wrote: post #107

Earlier quoted context omitted.

When possible, I prefer to do away with objects and have functions with types. X in, Y out.

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)).

> methods are exactly that as well, only that

Exactly, except for implicit types and modifying state, indeed. Those are the reasons why I prefer the above.

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

#127

Post by orthoxerox »

tcfhgj wrote: post #100
dkdbejwi383 wrote: post #37

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 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 b…

Premature dryness is the real issue, not the principle itself. When you catch yourself fixing the same code in multiple methods again, it's a good time to stop and refactor.

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

#128

Post by davidkunz »

clnq wrote: 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…

S - Spaghetti: Weave a tangled web of code, just like a master chef crafting a delicious pasta dish. Complex code is the key to intrigue and job security.

P - Precarious: Make sure the code is fragile, such that any minor change could lead to a cascade of issues. This keeps everyone on their toes and ensures that only the bravest dare to modify it.

A - Ambiguous: Write code that leaves others guessing about its purpose and functionality. Code should be a puzzle to solve, and the more obscure, the better.

G - Gratuitous: Don't be afraid to add unnecessary features and lines of code. After all, more code means more functionality, and who doesn't like more functionality?

H - Haphazard: Consistency is overrated. Embrace the chaos and develop without a plan, jumping from one idea to the next as inspiration strikes.

E - Entangled: Ensure that all components of the project are intricately connected, like a delicate lattice of spaghetti noodles. This guarantees that every change will have far-reaching consequences and keeps the team on high alert.

T - Time-consuming: Write code that takes a long time to understand, modify, and debug. The longer it takes, the more valuable it must be.

T - Tangled: Never refactor or simplify. The more convoluted the code, the more creative it appears, and the more impressed your colleagues will be.

I - Impenetrable: Write code that is difficult to test and verify, so that only the most determined and adventurous developers will dare to attempt it. This maintains a sense of exclusivity and mystique around your work.

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

#129

Post by akasakahakada »

tsimionescu wrote: post #103
akasakahakada wrote: post #77

Earlier quoted context omitted.

Now I understand why mordern web is slow as hell.

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.

Now you miss the point that you need to read that list from RAM in order to do for loop too.

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

#130

Post by riffraff »

rTX5CMRXIfFG wrote: post #50
riffraff wrote: post #29

Earlier quoted context omitted.

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.

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 m…

Sure, but being a bad programmer does not make you an "asshole", which is what the original commenter asked about.
Post reply on HN