This is such nonsense. Your examples are fine, because they're frighteningly simple - but even they break every rule of programming. If you want a function to be readable - and, more importantly, easy to debug, have only ONE point of return in it. Having return statements all over the place, with no Else, is ridiculous once you get past rudimentary levels of complexity. Go and read some Dijkstra.
"have only one point of return in it" is terrible advice. A great counterexample are guard clauses: they remove indentation and make code cleaner, making the flow of code easier to follow. Forcing you to have 1 return statement per function wil inevitable make your functions bloated.
If you are talking about the Dijkstra's Single Exit principle, then you are mostly misinterpreting him on a problem that doesn't exist anymore: when functions could return to multiple different places.
The point of the article is sound - try not to have branching paths inside a function. Perhaps a better solution in a language that supports it it to use guard clauses that throw exceptions if they don't follow the golden path rather than returning some kind of error state. But that's not always possible depending what you're coding in.
No it isn't. This is the sort of thing programmers with a few years' experience think is clever, but it's not: it's just another way of swimming while hog-tied and then saying, "Look what I can do". I mean - come on: do you really think throwing exceptions and returning error states is more readable than using "else"?
It depends, but oftentimes yes, because an "else" is a sign that your function is doing more than one thing, and a lot of people's programming philosophy revolves around making functions only do one thing.
I know - again: good for really simplistic stuff, but in the real world, if you make every function do only one thing, you have to have so many of them that your code becomes spaghetti. Besides, avoiding an else in one function simply means you have to move it to another, or use a case instead, which is a bunch of glorified else statements: if the program needs to decide a thing, it's going to need to decide it somewhere.
We're a place where coders share, stay up-to-date and grow their careers.
This is such nonsense. Your examples are fine, because they're frighteningly simple - but even they break every rule of programming. If you want a function to be readable - and, more importantly, easy to debug, have only ONE point of return in it. Having return statements all over the place, with no Else, is ridiculous once you get past rudimentary levels of complexity. Go and read some Dijkstra.
"have only one point of return in it" is terrible advice. A great counterexample are guard clauses: they remove indentation and make code cleaner, making the flow of code easier to follow. Forcing you to have 1 return statement per function wil inevitable make your functions bloated.
If you are talking about the Dijkstra's Single Exit principle, then you are mostly misinterpreting him on a problem that doesn't exist anymore: when functions could return to multiple different places.
Never mind: it's not as terrible as "don't use 'else' statements".
That's not a particularly constructive reply.
The point of the article is sound - try not to have branching paths inside a function. Perhaps a better solution in a language that supports it it to use guard clauses that throw exceptions if they don't follow the golden path rather than returning some kind of error state. But that's not always possible depending what you're coding in.
No it isn't. This is the sort of thing programmers with a few years' experience think is clever, but it's not: it's just another way of swimming while hog-tied and then saying, "Look what I can do". I mean - come on: do you really think throwing exceptions and returning error states is more readable than using "else"?
It depends, but oftentimes yes, because an "else" is a sign that your function is doing more than one thing, and a lot of people's programming philosophy revolves around making functions only do one thing.
I know - again: good for really simplistic stuff, but in the real world, if you make every function do only one thing, you have to have so many of them that your code becomes spaghetti. Besides, avoiding an else in one function simply means you have to move it to another, or use a case instead, which is a bunch of glorified else statements: if the program needs to decide a thing, it's going to need to decide it somewhere.