Me in a test:

if(boolean)
return value;
return something_else;

I then lost 2 marks for not having an else statement -.-

Ask why?

You’re right, the second return becomes the else.

You’re wrong, as you now have multiple return points in your function/method. Which can lead to unclear returnable results if this keeps growing.

1 entry + 1 exit is what you should be doing.

@C0D4 it was litturally a 3 line function, so it was pretty clear what was going on.

ReSharper even recommends removing the else if you don't do anything special in the else prior to returning.
I don't see why one wouldn't do this.

@LavaTheif today it’s 3 lines, tomorrow it’s 300 lines and 20 return statements.

@zotigapo I asked why I dropped 2 marks, he said because I didnt gave an else, then he confused himself when he realised it works

@C0D4 that aint how it works

@ganjaman someone should have told the previous dev of a project that 😥

@C0D4 While I don't say you're wrong, there is a concept utilizing "early returns"

@Kimmax it’s one of those pesky things that no ones really right.

I find for short blocks, early exits are usually fine, as you can clearly tell what is going on without too much hassle, But for long blocks having multiple exists can lead to unpredictable results when the conditionals haven’t been set out well or rely on a bunch of dynamic values.

Aka: spaghetti gone bad.

@C0D4 true.
I also often see very long code blocks with improvable code in general, speaking of abstraction and outsourcing functions etc

Not saying that all long code blocks are wrong, but often they can be improved to further increase the quality of the code

@C0D4 when it becomes 300 the issue doesn't become readability, it becomes a question of why is it 300 lines, then you're doing it wrong

@C0D4 And OP was talking about a short blob of code.

return condition ? value : something_else;

@xonya I like this approach better

@xonya I wonder if my teacher would understand that tbh xD

Should have used ternary.

One has to love people who just screw you for not being more like them.

@irene Well, I think that if the line is very short it improves the readability.
Something very simple like this:
return myBoolean ? "Yes" : "No"

It's just a tool, you can use it in a good way or in a bad way.

LOL I always coded this way.
Cannot imagine how it can be otherwise.

@irene Also: "switch" exists.

@C0D4

I disagree. Early returns are the bread and butter of readability in my opinion.

Our code style guide explicitly forbids using else statements, and prescribes the "happy path" method: You check the input using simple if statements, return early if needed, and put the "happy case" (nothing is wrong) at the bottom of the method.

And on a VERY related note, methods should never be longer than 10-20 lines, for readability, and SRP, and unit testing, etc.

I personally prefer pattern matching or guards, with option/maybe/either/monadic return types, but that's not always available in every language.

@finiteAutomaton Also you don't have to ever use switch or if (https://francescocirillo.com/pages/...)

@irene Anty if campain. They promote design patterns that reduce the amount of IF's you type in your code. But they also provide very expensive courses. One way or the other less IF statements in the code is always good.

@andros705 use objects instead of ifs?

You have some explaining to do since I would actually like to see how you handle conditional pieces of logic without having anything to differentiate the logic.

@bittersweet +1 for your style guide

For instance golang encourages this kind of pattern for capturing and returning errors, leaving "happy path" for return value. In many cases this embraced readability.

Btw I would be more convinced if the marks deduction was for the missing curly braces…

@C0D4

Go check Rust's Pattern Matching:

https://doc.rust-lang.org/book/...

Or check Haskell's guards in attached screenshot (from Haskell book).

In Haskell you can even pattern match by defining a function multiple times:

f :: Int -> Int

f 0 = 1

f x = x * 2

That's a function which always takes an int and returns an int, and will always double the input except if the input is 0, then it will return 1. In Haskell, pattern matching is commonly used for recursion:

map _ [] = []

map f (x:xs) = f x : map f xs

map anything to an empty list gives an empty list, map any function to a list will apply the function to the first element (x), then recursively apply the map to the tail of the list (xs).

const a = true

// Instead of if()
if (a) {
console.log("World");
}
// use (&&)
a && console.log("World")

// Instead of nesting multiples IF's in a function
function returnSomething(value) {
switch (value) {
case 'one': return 1
case 'two': return 2
case 'three': return 3
}
}
// Define multiple functions
function returnOne() {
return 1
}
function returnTwo() {
return 2
}
function returnThree() {
return 3
}

// Declarative programming
function isOne() {
return value => value === 1
}
function isTwo() {
return value => value === 2
}
function isArray() {
return value => value instanceof Array
}

function check(value, checks) {
return checks.every(check => check(value))
}

console.log(check(1, [isOne(), isTwo()]));

// React does something similar, check https://reactjs.org/docs/...
// to see how smart it is

@irene I cannot disagree.