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

141–150 of 170 posts

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

#141

Post by senbrow »

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…

DRY should really be "DRA" - don't repeat abstractions (which admittedly isn't as catchy).

The problem with DRY is when abstractions with currently identical implementations are given a single interface, even though they're logically distinct.

Then, when those distinct abstractions' implementations need to diverge, you've got a rats nest of references to manually pick through and separate out.

Or worse yet , the mistakenly-shared interface becomes parameterized, leading to a horrible mixing of requirements and concepts that may never be untangled if the original intent is lost to time.

Obviously DRY is great when you can consolidate multiple implementations that are actually a single abstraction, but it can really go off the rails if the motivation for the mantra isn't understood.

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

#142

Post by sodapopcan »

carlmr wrote: post #68
laerus wrote: post #61

Earlier quoted context omitted.

DRY only paired with the rule of three (or more)

That, or the code block is sufficiently big and similar. I remember a ex-colleague of mine who copied a 1000 line function, changed a parameter, and didn't see anything wrong with it.

I had a coworker who did similar. It was essentially the entire frontend for an order application (back in the jQuery days), a few thousand lines. That was all copy/pasted, changed to deal with the case of when there are no orders (which only ever happens once since this was an in-house system) and those massive chunks were wrapped in an if/else.

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

#143

Post by numbsafari »

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.

When I was younger, I really thought this was the be all end all, and probably committed more programmatic sins due to trying to achieve DRYness than anything else.

Often times it seems like we aim for DRY at the expense of simple, or idiomatic code. It also has a nasty habit of making code difficult to change since it leads to a lot of premature coupling, where someone sees a repetition and naively assumes that that needs to be eliminated, when it might literally be a naturally independent value.

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

#144

Post by bcrosby95 »

carlmr wrote: post #68
laerus wrote: post #61

Earlier quoted context omitted.

DRY only paired with the rule of three (or more)

That, or the code block is sufficiently big and similar. I remember a ex-colleague of mine who copied a 1000 line function, changed a parameter, and didn't see anything wrong with it.

I recently had a junior copy paste a 20 line code block rather than add an extra 'or' to the if statement.

Hey, rule of 3 ;)

Anyways, guidelines are just guidelines, regardless of what you come up with you can break it.

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

#145

Post by gregfjohnson »

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.

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

#146

Post by zelphirkalt »

andrewingram wrote: post #98
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.

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

I agree with rather having good or correct abstractions than saving LOC. However, a bad abstraction can give readers/devs the wrong idea about what is behind it, how it works or how it can be used and when to rely on it. Unreliable abstractions are terrible. Leaky abstractions are also terrible. Both introduce a lot of mental load overhead.

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

#147

Post by gizmo »

whstl wrote: post #122
gizmo wrote: post #41

Earlier quoted context omitted.

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

His book was pretty good, and I very much agree about the importance of good interfaces. It's the essence of computing, because file formats, data types, and protocols are just interfaces by another name.

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

#148

Post by riffraff »

dagw wrote: post #138
riffraff wrote: post #132

Earlier quoted context omitted.

But we're those critiques of him being a horrible person? I disagree with some of his technical ideas, but that in itself would not warrant such a characterization.

I have honestly never heard (or made) a critique of him as a person. In fact the little I have heard about him as a person has generally been positive.

ok but the original comment called him an "asshole", which is about the person, not his technical ideas.

I can dig up some instances of people being angry at him, but honestly, it's a 70+ republican, you can easily imagine the situations he gets into.

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

#149

Post by zelphirkalt »

tsimionescu wrote: post #42
josephg wrote: post #13

Earlier quoted context omitted.

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

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.

At sizes/number of items, where this holds true, maybe the choice of data structure is not as important. It becomes important, once the number of items in that collection increases and then always linearly scanning the whole array will become a problem. Just use the appropriate data structure and be safe in the future, taking a negligible hit for small input sizes.

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

#150

Post by zelphirkalt »

MoreQARespect wrote: post #16
BulgarianIdiot wrote: post #5

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.

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.

Start with simple. Don't involve objects and classes and whatever, until there is a need for them and you can justify them. Don't use them because OOP. If your program or part of a program is fundamentally just a complex function, then write it as function(s).
Post reply on HN