The advice about if up is not bikeshedding though, it is the exact kind of architectural choice you're saying one should decide on. Don't believe me ? Well imagine you have inputs, where should you validate them ? According to this rule of thumb it's at the topmost level, when they are received. Well that seems super sensible, and it's typically something that helps with understanding the code (rather than checking them at thw very last moment). Also for proofs that's technically necessary to allow the preconditions to "percolate up", which has the same effect of moving the if up.
So the first advice is definitely not bike shedding, the second one I'm not so clear though ;)
> it is the exact kind of architectural choice you're saying one should decide on.
While I can't speak to what the OP had in mind, architectural concerns are definitely not inside a function. Even connecting individual functions/procedures barely registers at the smallest, most granular scale of architecture.
Of course, our programming languages for the most part don't let us express architectural concerns...so here we are.
But the article wasn't about "validate inputs at the boundaries" (which is a semantic concern), it was about "push your ifs up" (which is a syntactic concern).
I agree that in the provided example, those two seem to somewhat coincide (although it's hard to say, given that the author makes an effort to give their functions names such as "frobnicate" that don't indicate their purpose), but in the general case that doesn't have to be true.
Are we reading the same article? There is zero concern for syntax.
The first point is literally what you said. Write functions with clear interfaces. If your function doesn't handle None, make its argument type reflect that (Walrus instead of Option<Walrus>).
The second point is about performance. Hoist branches out of loops, and process batches so any constant cost is amortized over the batch. Is that even controversial?
> the author makes an effort to give their functions names such as "frobnicate"
Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example.
> Are we reading the same article? There is zero concern for syntax.
By "syntactical" I mean "concerned with the surface level appearance of low-level code structure".
> Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example.
Only if you think that guidelines about how to write code should be devoid of the context of the problem you're trying to solve. I happen to think that this is mostly wrong.
Well, let's consider the three examples the author gives for "pushing ifs up":
The first one isn't even a proper example because they write "push the if to the caller", but doesn't actually show the caller. So the good and bad examples aren't even straightforwardly comparable. For the second example, calling g() has exactly the same behaviour as calling f(), and for the third example, the behaviour also remains identical with or without the enum.
I don't see how this is any more than just pushing code around without having more context about these methods and who calls them.
So the first advice is definitely not bike shedding, the second one I'm not so clear though ;)