Golang code review be like

> oh no, you used prohibited `else` keyword

Context? Dosent matter. Its banned, mkay?

Fix? Oh you know its hell to read now

Ah yes let's ban an entire keyword from a programming language that has a great total of like 3 keywords

How TF?

Haha I know that some devs consider "else" to be evil. I understand their points. But even the most hardcode opponent of "else" wouldn’t go as far as banning it. Because context matters.

I still don't understand why we hate on else.

Maybe if all your functions fit on one screen it can be refactored into an early return, but if you could be using an else branch then an early return is actually concealing the fact that the long path is in some sort of discourse with the body of the condition.

Else branches restore some sort of balance by reenacting effects of the true branch such as producing fallback values. If this is your case, you should be using an else. If the true branch is a shortcut and the false branch does more work, it should probably be an early return.

Depends on context.

Complete banning is surely wrong, but many else branches are just out of lazy ness.

Return early, keep the flow of a function readable and you will have very very few else branches.

But go actually has goto.
Explain that, mf-er.

sorry to be the stupid here, but why and since when is 'else' considered harmful?

isn't
'if thing
do stuff
else
do other stuff
fi'
basic programming? like what exactly is bad about it and how do early returns even improve that? isn't that more obfuscating since you'd have to always check if code is reached or not?

@Jedidja

Becouse when used inapprioprietely it can incerase code complexity or make it harder to read.

But there are people who believe that this means that they should NEVER be used, due to ma' complexity and stuff.

@Jedidja

The important nitbit is "flow of code".

- 1st example

The first case makes it blatantly obvious that you want "bla.value".

Everything that is not "bla.value" is a corner case.

Looks innocent at first hand.

But if you add more specific conditions, it becomes obvious why the first one is "easier".

- 2nd example

One *could* write my whipped up example differently, but this is what mostly happens.

People just stick it where it fits.

There is a second reason why I dislike the "else return <default value>;" case...

The function has no return at the end. The return is "implicitly" coded into the else branch.

This might sound "paranoid"... But I've seen it too many times.

People rewriting if / else conditions and overlooking this "implicit" default.

When you have an unconditional, explicit return stating what the function should return if all goes well, it can prevent a lot of "ouch" situations.

Plus it makes it pretty much obvious - without thinking about logic - what the function should do.

Which is important for debugging.

When you have to decipher branching to **guess** what should be the expected result, oh boy.

You're up for a wild ride.

https://zerobin.net//...=

1st and 2nd example are here.... DevRant retarded.

@IntrusionCM Does Go allow you to explicitly state the return type? If so, wouldn't it make sense to enforce that rather than banning very useful and fundamental control structures because they don't work well with the implicit deduction of something so intrinsic to correctness as return types that should never have been optional to begin with?

Edit: removed question answered by example

@lbfalvy Yes, but primitive returns exist and an object is primarily a data container.

Return types help tremendously, but still an object can have different "states" (as in containing different data) depending on how it was constructed.

A return type is helpful, but not a "full" representation of what is expected

@IntrusionCM I don't see how the state of the object relates to the problem at hand. You can't forget about a return branch if all return types are indicated. As for in-function branching I would argue that it's easier to forget about internal false branches (such as those after a conditional continue in a loop) and their relation to their respective true branches if they're not properly coupled with an else statement.

@lbfalvy

Think of fluent interfaces and object assignment as one example.

Even an immutable object needs to be created.

That's what I meant by state of object.

Branches with mutations of objects or creating values for a later object instantiation.

Hope this clarifies it.

@IntrusionCM The symmetry between the branches (eg. something needs to be initialized by the time either is done) is reflected in the else keyword. If you omit that, the two branches become logically disconnected, so you must rely on static assertions such as an enforced return type to guarantee correctness.

@IntrusionCM I really don't see how your example alters this fundamental approach. Logical relations between snippets should be reflected in code structure or enforced by static analysis. If the only thing the branches have in common is that they both produce the same return value and that return value is explicitly stated and enforced by the compiler, an early return is safe. If there's some mutation it becomes extremely important that any conditions the mutation depends on, including early returns before it, are immediately apparent just by looking at the impure line. An else statement helps with this.

@lbfalvy my brain is toast.

I try to come up with something tomorrow, but today brain cannot articulate well. Amongst other things.

Brain still toast.

Nearly killed myself today by mixing up the bag of "aci pul biber" ( https://en.m.wikipedia.org/wiki/... ) with the bag of california reaper (roasted and grinded)

I noticed it because I was annoyed that I smeared some vegetable juice on the ziploc bag of california reaper.. I ungently let the bag fall down , so I don't contaminate the dried stuff with wet vegetable juice.

Had the not so bright idea to dip my finger in some of the flakes on the countertop and to try it with the vegetable sauce.

Dish saved, me pretty much dying for half an hour.

California reaper dried and grinded is really... Bad. Especially when you put like a finger full in your mouth.

I follow the evil else idea, but there are still use-cases where it's needed, for example when an early return doesn't make sense.

I do often write comments asking for inverted if-statements and removing elses, who knows you might have me as a reviewer.