Me too! I was soo excited to discuss these things with the author himself on LinkedIn directly - only to be met with a very harsh appeal to Authority Bias. That was disappointing, indeed.

yep that's also what i was expecting

I love Rust so much! Thank you for the idea, maybe I'll do a video on that soon.

Don't forget your diploma: markjivko.com/smelse/

Smelse like a scam to me honestly. I'll stick with Anti-If

Don't say bad things about my precious! 😂 I'm kidding. Do-while-false is just a flavor of the Guard Clause, but using block breaks instead of return statements. I prefer it to the guard clause because it allows me to have only 1 return statement per function. So that way I can pretend that functions are SiSo - single input, single output. It's a pattern I like personally, not one that everyone should use.

I appreciate that!

Do while false is just a flavor of the Guard Clause. I prefer it because it allows me to have only 1 return statement per function, following your "happy function" definition of a final, easy to follow return. I like siso functions. That is, single input, single output. One set of arguments, and only one return statement. Do while false is a great tool for that.

The original post was probably not about branchless programming optimizations. I doubt that the course author cared about performance but rather what looks "nice" (by his standards) in a codebase

Thank you! do {} while(false) is not as evil as go-to, but they are definitely cousins, that's for sure.

I like your insights! Indeed, the ternary operator is yucky. On the other hand, I don't mind it that much in the world of React components. Regular expressions are useful too - sometimes. Other times, you're better off writing a tokenization algo yourself. There's this thing called "creative limitation", where constraints seem to have the interesting effect of fostering creativity. So if you're given a programming task but you're told not to use "if" statements (or avoid them), that constraint forces you to look for alternative patterns - such as polymorphism and higher order conditionals. However - as always in SWE -, more creativity is not a desideratum. I would even go as far as saying a code that tries to be "very clever" should be rewritten from scratch. Attempting to avoid "if" statements just for fun is an interesting thought experiment. Using that game in production code, on the other hand, is just plain wrong as it leads to "over-engineering".

My takeaway is this: if you truly want to optimize performance, focus on O(n); logical lines of code and number of "if" statements are not important. If you want to optimize loading times and memory performance, polymorphism is probably worse than simple if statements. If you want to sell a course on SOLID principles and you need a catchy motto, say something weird. Our lizard brains have a tendency to identify and remember weird.

​@@markjivko The large discrepancy in speed between memory and processors means everything that needs best performance, needs to take that into account. This means favoring arrays, group data together that gets accessed together, high information density data-structures, avoid unpredictable branches in inner loops. So less per-object thinking and more per-set/array thinking. Because in reality we hardly ever need to act on just one thing and nearly always need to do it for a large set of things. This works because modern processors deal with the memory/CPU speed discrepancy using caches and various prediction/prefetching hardware. It is easy to predict + fetch the memory for the next/previous element in an array. So linearly accessing the array is more efficient than some fancy structure that in theory requires less steps to do the same actions. As for polymorphism, that is just one way things can become unpredictable for a CPU. If an array contains all objects of the same class (all dog/cats, whatever), it wont really hurt performance. Because the pattern is predictable. If an array however contains a random mixture of both, then performance will suffer or even tank.

❤️

Exactly. The "smelse" example is just the Guard Clause implemented within a while block. That lonely FAQ question in an accordion just shows poor UI planning. But if you want to take it one step further, it confirms that the author prefers complexity over simplicity. Polymorphism over simple if statements. Design patterns and expensive OOP over "simple" functional programming. In my opinion simplicity is always a desideratum in Software Engineering. But hey, I didn't "pioneer TDD" or whatever.

The guard clause using do while(false) can be implemented in most programming languages, even the stinky ones.

agreed but does anyone know why the syntax for switch is so god awful disgusting in seemingly every language? is there a language where a switch feels good to write?

I think that's by design, so you use it less 😂

​@@forasagorust and zig have a decent syntax. The problem with switches in a language like c is that is uses label syntax to handle each case and you have to break out of the switch after every one of them. That syntax looks very out of place. In languages like zig you can just: switch (x) { 42 => { // Your logic }, // other cases... else => {} }

It really depends. If you have 2 condition it literally doesn't matter. They're both branching. No performance gains.

​​@@maksymiliank5135 pattern matching is not magic. It's just pushing the responsibility of deciding whether to use if-else or switches to the compiler.

I agree with you. But I'm not sure it's a need to stop others from working rather than a constant need to prove they are smarter. There's a saying, "those who can't do, teach, and those who can't teach, teach sports". I believe academic types have this frustration, a sort of inferiority complex. They need to constantly use big words and complex imagery to convey meaning. Whereas any programmer worth his salt knows you should "keep it simple, stupid", and complexity is the enemy of engineering. Secondly, academic types also need to pay those bills. Beyond tenure there's not much you can do - so you sell your "authority". You write books, you attend conferences, and you create courses and programs that have your signature on them. You constantly remind people how well known you are and how much you contributed to Scrum or whatever and you keep on tapping into people's authority bias to make a quick buck until your name becomes synonymous with charlatan at which point you retire to a villa in southern Italy.

I don't like "else if".

The "do while false" approach is just a flavor of Guard Clause. I prefer it because it allows me to have only one return statement per function - respecting the "single input, single output" principle. I know the "single return per function" preference is controversial, so I did not mention it in this one. Maybe I'll go over it in some future video. Regarding the jumps in PHP - I have zero clue whether a break is more "optimal" than a return. I would bet that there's no significant difference between the two at any scale. Remember that PHP is a scripting language - code is interpreted, not compiled.

@@markjivko Thanks for the well thought out reply. Earned a sub. I was under the impression most production deployments of php had JIT compilation these days, so it would apply to hotpath code at least. I am absolutely interested in your single return statement per function preference. I've actually never heard that before, and I am not sure if its a matter of code style or maybe something PHP does that you are optimizing around? Because the downside I see of what you did here, assuming the JIT is not smart enough to optimize it out, is introduce a pointless branching conditional at the end. Is it not possible to break out of a block that is not a loop in PHP? I know in like C or zig or rust I can create a named block and break out of it.

Awesome thank you!

I have mixed feelings about the ternary operator. Kind of makes sense in react components, not really easy on the eyes otherwise. As always in SWE, "it depends".

@@markjivko Ternary is useful in Typescript for `ArkType` codebase :) It is simple and good until it is not :) Agreed on it is controversial! The `prettier` team spent lost of time to format it correctly when it breaks to a new line!

Great question! Returning early is technically called "The Guard Clause". The "do-while-false" structure is just a flavor of the guard clause with breaks instead of returns. I prefer this approach because it allows me to have only 1 return statement per function. This is a personal preference, of course, and not something that should be considered best practice. I like to look at functions as SISO - single input, single output. Functions (usually) have only 1 set of parameters, and that is the "input". Having only 1 return statement at the end of the function just feels right to me. Obviously, "impure" functions have more than 1 input: arguments, use() statement, globals and superglobals etc. ($input) => { $output = 0; do { /* change output */ } while (false); return $output; }; I just prefer the simplicity of SISO.

@@markjivko I like it.

😂