[Tainnor]

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.

[mike_hock]

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.

[Tainnor]

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

[mike_hock]

Yes, I think it's possible to have discussions on an abstract level and not everything has to be a case study.

[pjc50]

"If" is semantic!

[Tainnor]

Its location in the codebase isn't.

[patmorgan23]

If it changes the behavior of the program it is.

[Tainnor]

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.