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 ;)
mpweiher|2 years ago
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.
Tainnor|2 years ago
Tainnor|2 years ago
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.
mike_hock|2 years ago
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.
pjc50|2 years ago