Your first example doesn't even do the same thing. Now if you had a RETURN involved, then it would be the same and you drop the else...

Let's say you had a variable "a" and your first event adds 3, your second event adds seven. In the first example it outputs 3 or 7. Your rewrite without else outputs 10 or 7.

There ARE reasons to not else. Throw, Return, or break/continue inside a loop... But to say it's the same thing without an example where it's the same thing?

Which is interesting when that's exactly what your second section does. Why are those two separate points/sections?

Though if it were something simple like that, I'd probably use two ternary operations.

Since your third section involves the same Throw, why is that multiple else. || (logical or) exists, use it.

Nice that you finally got to a ternary though.

Section 4 looks like the typical load inducing "functions for nothing" crap that should probably just be a switch/case, though that would depend on the actual usage scenario.

That code is particularly bad since you're declaring them every blasted time that function is called, introducing even MORE execution overhead to what's already slow thanks to the functions.

Remember, function calls have a pretty nasty overhead. PUSH arguments, CALL, PUSHA, MOV BP, SP; then run the function code, POPA, RET argument size. Don’t even get me STARTED about the stack frame shift / heap / DS changes needed for object methods.

And in section 5 you again repeat the card-stacked code where you just said don't else when it's a return. You say "tho we can easily replace" and then you don't do it?

Hence why once again you end up throwing 3k of code relying on dozens of objects and methods in the slowest manner possible at doing less than a quarter of a K of code's flipping job!

I don't get where you think that wreck of 5 line functions for each and every state is magically superior -- or cleaner code -- than:

public static string PrintOrder(Order order, string formatType) {
switch (formatType) {
case 'Json':
return JsonSerializer.Serialize(order);
case 'PlainText':
return $"Id: {order.Id}\nSum: {order.Sum}";
return "Unknown format";

Which executes faster, and to be frank is CLEANER and easier to follow.

I see this a lot where people think that these function calls spread out all over creation are “easier” to write or follow than switch/case or if/else… when you could just put it right there without the overhead. HOW is that train wreck of methods/classes/functions cleaner/clearer/better than a simple switch?

I mean, you’re right, if/else isn’t always the answer, and people do use else wrong one hell of a lot… but where is the “advantage” in the train wreck of code you’re presenting as an alternative?

Because this:

public class OutputFormatterName : Attribute {
public OutputFormatterName(string displayName) {
DisplayName = displayName;
public string DisplayName { get; }

public interface IOrderOutputStrategy {
public string ConvertOrderToString(Order order);
public class OrderJsonOutput : IOrderOutputStrategy {
public string ConvertOrderToString(Order order) {
string json = JsonSerializer.Serialize(order);
return json;

public class OrderPlainTextOutput : IOrderOutputStrategy {
public string ConvertOrderToString(Order order) {
return $"Id: {order.Id}{Environment.NewLine}Sum: {order.Sum}";

Sure as shine-ola isn’t an improvement. You can’t even find the forest for the trees in this “object for nothing”.

As someone else joked in another of your posts, this is why “Hello World” is now 32 megabytes.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store