Comment by BoorishBears

Comment by BoorishBears a day ago

My mental model: align with the world the very specific code I'm writing lives in. From domain specifics, to existing patterns in the codebase, to the stage in the data pipeline I'm at, performance profile, etc.

I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code.

It's telling they tend to resort to made up function names or single letters because at that point you're setting up a bit of a punching bag with an "island of code" where nothing exists outside of it, and almost any rule can make sense.

Perfect example is the "redundancies and dead conditions" mentioned: we're making the really convenient assumption that `g` is the only caller of `h` and will forever be the only caller of `h` in order to claim we exposed a dead branch using this rule...

That works on the island, but in an actual codebase there's typically a reason why `g` and `h` weren't collapsed into each other to start.

jonahx 21 hours ago

I feel this kind of critique, which I see often as a response to articles like this, is so easy as to be meaningless. How is one supposed to ever talk about general principles without using simplified examples?

Aren't you just saying "Real code is more complicated than your toy example"?

Well sure, trivially so. But that's by design.

> Perfect example is the "redundancies and dead conditions" mentioned: we're making the really convenient assumption that `g` is the only caller of `h` and will forever be the only caller of `h` in order to claim we exposed a dead branch using this rule...

Not really. He's just saying that when you push conditional logic "up" into one place, it's often more readable and sometimes you might notice things you otherwise wouldn't. And then he created the simplest possible example (but that's a good thing!) to demonstrate how that might work. It's not a claim that it always will work that way or that real code won't be more complicated.

Reply View 2 replies

BoorishBears 3 hours ago

Well I guess some comments need to be considered in totality, rather contextomies that enforce whatever point you're trying to make :)
I spelled out the problem pretty clearly.
> I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code.
It's the wrong level of abstraction to form (useful) principles at, and the example chosen is just a symptom of that.
I'm not sure why we're acting like I said the core problem with this article is that it uses simple examples.

Reply View | 1 reply
- jonahx an hour ago
  
  Because that was the only evidence you offered to back up the claim you just quoted. I understood the claim... it might be interesting if you presented some specific example of your own as counter-evidence, instead of straw-manning the article's intentionally simple example as too simplistic.
  Your argument sounds like, "I'm so smart and enlightened, I've moved beyond simple heuristics like this." Okay, but the author is also a smart, experienced programmer and is apparently still finding them useful. I am also experienced, and personally find them useful.
  I'm not against some argument that there is actually an even better, deeper way to look at these things. But you didn't make that argument. And, perhaps unfairly (you tell me) I suspect your response to that will be that it's all too gossamer, or would take too long to explain....
  
  Reply View | 0 replies