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

101–110 of 170 posts

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

#101

Post by BulgarianIdiot »

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.

The only objective rule in SOLID is L:

"Objects of a superclass should be replaceable with objects of its subclasses without breaking the application."

And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X.

The other rules are so vague and subjective, that you can spin them any way around to prove someone's code sucks if you choose so. Which is ideal for selling people books & consultation services. And for Internet arguments.

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

#102

Post by tcfhgj »

leidenfrost wrote: post #78
carlmr wrote: post #68

Earlier quoted context omitted.

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.

Why do you have a 1000 line function in the first place? Sounds like an entire class of methods in a single structure.

The function contained 300 lines which he copied and pasted twice, because DRY and extracting into a function right away is dumb /s

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

#103

Post by tsimionescu »

akasakahakada wrote: post #77
tsimionescu wrote: post #42

Earlier quoted context omitted.

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.

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.

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

#104

Post by alanbernstein »

edumucelli wrote: post #10

It is laughable talk about "Don't Repeat Yourself principle" on a strongly biased towards Golang article. A language that took 13 years to add a simple method (Index) that helped the programmer to find an element in an array (slice). Before that you had to write a for loop every time you wanted something from an array. Talk about "DRY" ... That is everything but "simple" as described in the article.

Huh?

> But there's nothing wrong with repetition in itself. I say again, there's nothing wrong with repetition in itself: a task we do many times is probably an important one. And if we find ourselves creating new abstractions to no purpose other than avoiding repetition, then we've gone wrong somewhere. We're making the program more complex, not more simple.

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

#105

Post by josephg »

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.

Maybe. That depends on the map implementation. In javascript I’m pretty sure small maps are implemented as lists anyway. I wouldn’t be surprised if Go is the same.

Searching through a list is definitely more complex to write, and it carries the danger that your list will grow and you wont change your code.

The speed difference will only matter at scale - so if you have a lot of small lists with items you’re searching for. That happens, but it’s uncommon that it’s the best approach. I probably use find() / indexOf() about once every thousand lines or so.

The commenter above implied it’s a very common operation in their code. (So much that they’re angry about Go not having it in the standard library). I don’t know about the commenter above, but I’ve certainly seen a lot of novices at programming massively overuse lists not because they’re performance experts, but because they don’t yet understand when a map might be a better choice.

So I must say I understand Go’s choice here. Go is a paternalistic language where the obvious choice should usually be the right choice. Go is actively against clever optimizations philosophically. I can imagine rob pike being quite pleased that slow, linear scans of lists are awkward in his language. This sort of judgemental paper cut is sort of Go’s whole thing.

If you don’t like being looked down on by the compiler, use a different language. Or use maps in your Go code. Go isn’t designed to be microoptimization friendly.

(Source: I sat about 2m away from Rob Pike for nearly a year while he worked on Go, before it hit 1.0. Go isn’t designed to be a language for people who think about cache lines.)

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

#106

Post by carlmr »

leidenfrost wrote: post #78
carlmr wrote: post #68

Earlier quoted context omitted.

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.

Why do you have a 1000 line function in the first place? Sounds like an entire class of methods in a single structure.

Created by the same person. But the way he doubled his LoC contribution in this PR you could imagine why.

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

#107

Post by mejutoco »

BulgarianIdiot wrote: post #101
MoreQARespect wrote: post #16

Earlier quoted context omitted.

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.

The only objective rule in SOLID is L: "Objects of a superclass should be replaceable with objects of its subclasses without breaking the application." And when you decipher it, it literally means "all X should act like X", which is already obvious. I.e. if "Y extends X" then Y is also X, so Y should act like X. The other rules are so vague and subjective, that you can spin them any way around to prove someone's code…

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

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

#108

Post by [deleted] »

leidenfrost wrote: post #82
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.

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.

[deleted]

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

#109

Post by postalrat »

fendy3002 wrote: post #88
physicles wrote: post #48

Earlier quoted context omitted.

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

Often the best way to DRY something if to let it sit in the sun a while where everyone can see it.

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

#110

Post by throw1234651234 »

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.

DRY is priceless, and if your argument is to avoid DRY in very specific cases, state that specifically.

DRY, when used with functional, well named code is the number one thing keeping a codebase easy to read. There should be one way to achieve something well-defined like save/edit/delete an entity, check a file type, url encode a string, etc.

This ALWAYS leads to much easier code fixes AND much easier refactoring.

Post reply on HN