re: There's no "else if" in JS VIEW POST


There is a golden rule: if statement is always a sign of a design flaw. Period.


How can you have any flow control without some sort of if-statement?

E.g. with FSMs. E. g. with class hierarchy. E.g. with pattern matching. The list might be easily prolonged.

But surely some tasks just require if-statements? What if you receive an integer from user input and want to know if it is positive or not? What if you want to filter out all odd numbers out of a list? Isn't pattern matching on something with two cases just an if-statement with the first case as a condition?

Not really. Well, sometimes, very rare.

What if you receive an integer from user input and want to know if it is positive or not?

This might happen in some beginners’ exercise, not in the real life. I won’t allow users to input both positives and negatives the same way and I would immediately raise on any unexpected input.

What if you want to filter out all odd numbers out of a list?

I would use the standard library filter function/method, like (Elixir example, but it does not matter, the same is available in Ruby, Python, Perl for sure): Enum.filter(input, &is_odd(&1)).

Isn't pattern matching on something with two cases just an if-statement with the first case as a condition?

Pattern matching has many clauses by default, hence the code might be easily extended when needed, unlike if. Also, pattern matching is significally faster. And, the last but not the least, I usually don’t have to choose between two conditions in the middle of the code, because I think about the proper design upfront.

Alright, but then you are just hiding the if-statement within the is_odd method. There is no sane way to implement these types of functions, that take an integet and return a boolean, without if-statements.

I highly doubt that pattern matching can be faster than if-statements in any language, since pattern matching on non-enum types would have to be implemented using conditional jumps (i.e. if-statements) in the underlying machine code or VM code.

I never said I am advocating the senselessness of conditional jumps in the underlying assembly / machine codes. That is obviously impossible.

What I said is if statement as it is, is hardly maintainable.

Hey Aleksei! I'm really interested to know more about your vision about this subject. I'd love to read an article about that. If you have some time to write about this, I would be really glad! :)

I will do, sooner or later. The subject actually bugs me :)

That'd be nice. A lot of this discussion is what not to do, but that isn't worth much without alternatives and example use cases.

Alright, but then you are just hiding the if-statement within the is_odd method. There is no sane way to implement these types of functions, that take an integet and return a boolean, without if-statements.

To be fair - one could also claim that if statements are just hiding the conditional jumps. Creating better abstractions over problematic implementations is a virtue.

That was my point, Idan; if-statements are just conditional jumps, and you need those to be Turing complete. I disagree with the idea that if-statements are always a design flaw, because that just leads to using overabstracted solutions for simple problems, e.g. using pattern matching on a boolean condition.

I agree with your virtue, I just don't see something as integral as the if-statement as a 'problematic implementation'.

I understand whose is in the functional is alergic to IF statement, but a coder can create a good program without a functional approach. Many developers write code in procedural mode, if you use GNU/Linux you'll know that in many files you'll find IF statements

One might use Linux for decades and never ever see a single line of the code.

That’s true, there are very specific circumstances under which if might be the best choice, but all those are exceptional nowadays. 99% of businesses use high-level languages and in high-level language, no matter whether it’s functional or not, ifs are a sin.

99% of businesses ????????
If you consider that COBOL has been back ...
If you consider that many banks prefer continue with old COBOL (not the new one) for the ATM services.
I you consider that big manifactures build products IoT with a poorly code and very buggy.
I think that you're developing for excelence, despite I've seen in your code of elixir-iteraptor some IF statement

Legacy is legacy, there is no doubt (although COBOL was invented as a most imperative language ever.) I admit I exaggerated the percentage, though.

I've seen in your code of elixir-iteraptor some IF statement

I never said I am perfect. If I had 72hrs/day I would be always writing the good code avoiding ifs. This is a solid settlement: I use ifs to save some time, while I still expressly understand I could do better.

I'm intrigued by what you said about if-statements. I'm curious to know how you would write the following callback function.

someRequest(URL, (err, result) => {
    if (err) {
    } else console.log(result);

I'm still a novice so it's difficult for me to imagine doing some things without if-statements. I would appreciate it if you could show me😅🙂.

You could use something like promises.

.then(result => console.log(result))
.catch(err => console.log(err));

Ooh. That's right. Forgot promises could do that😅. Thanks 😊


Then why is it there in the language? To put in other words, where does it make sense to use an if-else statement?


There are many things in modern languages that are just a matter of legacy. In procedural programming era (the most noticeable example would be FORTRAN) there were no paradigms to avoid conditionals. Nowadays we have plenty.

Using ifs inevitably leads to spaghetti code, that is hard to read and incredibly hard to maintain. Also, if violates the SRP principle out of the box.

Yes, sometimes if might be the best solution (when there are two possible outcomes, and there will be two forever, e.g. if hours < 12 then 'AM' else 'PM',) but the list of usages is very limited and in general there [nearly] always would be a better, cleaner and easier to support alternative.

This is incorrect. The inclusion of if isn't a matter of legacy, it's because if is a low level primitive that can be used to build higher level abstractions. That is why Lisp has if; the thesis of Lisp is to expose a small set of primitives, allowing developers to leverage those primitives to build the language they need. While I agree that many developers reach for if when a higher level of abstraction would be more appropriate, there should be no golden rule to "never use if". Sometimes a lower level of abstraction is what is appropriate for a task.


While I don't agree wth the premise that if is inherently bad in a non-functional programming language, having something in a language doesn't make it good. Many languages are extremely poorly-thought-out and nothing's perfect.


Saying that if-else statement are always bad isn't something I would do. As any other tools, it has to be use in the right place to be effective.
Sometimes, I do prefer a switch (or match expression). But sometimes, it just do not make any sense to avoid the if-else. As an example, when coding a game, you might want to know either or not an object is in front of the player. You will certainly use the dot product as it is cost efficient and then you will have to test if the result is zero or if it is a positive number above zero.
From my point of view, the if-else fits perfectly here. Again, his use has to be cautious.

At least, I think so.


In FP you could use filter instead of if, which makes your code more modular than stacking if on if.

In FP you could use filter instead of if

“In FP” preamble looks redundant here. All modern languages (save for, maybe, Malbolge,) allow filtering over stacked ifs.

The point I wanted to make was, "if you choose to do FP in your PL of choice you would use filter instead of if"

Unlike Haskell, JavaScript is not a purely functional language. Functions such as filter are recent additions to the language. If you look at the V8 source code for the filter function, you'll see this comment: "The following functions cannot be made efficient on sparse arrays while preserving the semantics."


That’s mostly not a matter of efficiency, it’s all about clean code.


My point was not about using if statement ... I just used that, because It's a starting point for everyone.
Most of use learn through cycle and conditional and variables... and most of the time, we just follow the rules. That was the point, not encouraging to use poor design.


Here are two real-world pieces of code I wrote yesterday. I describe the problem I'm solving, link to the relevant resources that led me to write that code, and include the if statement laden code I wrote. Your absolutism and your certainty has me rolling my eyes, so go ahead and prove me wrong! Rewrite my code without if statements in a way that's better: gist.github.com/JoshCheek/71623a73...


I don't understand how this could be true :/


I don't think one can design a computer without any logic gate. And, transformation doesn't change how a thing is designed.


This is really baffling me. What is the alternative? I don't think programming languages can be Turing complete without some sort of if-statement.

The only realistic way I can interpret your comment is that we should only use switch-statements, but that would just lead to

switch (condition)
  case true: ...

Switch is the way to implement the "else if" construct :)


I guess technically, if statements could have been omitted in this example (though there’d still be a conditional present).

function wow(arg){
  var o = {
    dog: "LOVELY",
    cat: "CUTE"
  return o[arg] || "gimme an animal";


I think above code needs one more condition.

function wow(arg){
  var o = {
    dog: "LOVELY",
    cat: "CUTE"
  return (o.hasOwnProperty(arg) && o[arg]) || "gimme an animal";


If I want to replace above code. I would do something like this. (with conditions)

const wow = arg => (
  (arg === "dog" && "LOVELY") ||
  (arg === "cat" && "CUTE") ||
  "gimme an animal"


can someone explain to me why you can use parathesis instead os curly braces with an arrow function? I was thought that the parathesis are used to indicate to the compiler that what is encapsulated in the parathesis are supposed to be treated as parameters, and what is in the curly braces are supposed to be treated as the logic.

This goes to the point trying to be made by Fabio Russo "the good parts or right ways to code...It's not really the best way."

Your information is not incorrect for regular functions. However, with an arrow function, you are allowed to use parentheses to represent a function body with a single statement (useful when spanning multiple lines).

There are other places you can omit things as well.


Single parameter, parentheses are optional

const myFunc = (singleParam) => {/* function body */};
// is the same as
const myFunc = singleParam => {/* function body */};

Multiple parameters require parentheses

const myFunc = (param1, param2) => {/* function body */};
const myFunc = param1, param2 => {/* function body */}; //Syntax error due to missing parentheses

Function body needs curly braces for multi-line command block

const myFunc = param1 => {
  console.log('I did something');
  console.log('I did something else');

However, if your body is a single line and you want to return the result, you may do any of the following (all of these return the value of name.toUpperCase()

const myFunc = name => {
  return name.toUpperCase(); // note the return

const myFunc = name => (
  name.toUpperCase(); // note, no return if in parentheses

const myFunc = name => name.toUpperCase();

It really helps if you have a command that spans multiple lines where you just want to return the result. So, for example, if you were dealing with a promise you could do either of the following:

const fetchUser = userId => (
    .then(rsp => rsp.data)
    .catch(error => {

const fetchUser = userId => {
  return fetch(`http://example.com/user/${userId}`)
    .then(rsp => rsp.data)
    .catch(error => {

Now, I understand that you're able to use arrow functions in more diverse ways, but after looking at the code I had trouble with I realize that pranay rauthu used a "hidden if-statement" how does one use the ampersand(&) to make a conditional, and to see if arg === some-value, and print a value based on what the client set arg equal to.

If someone has a response to my question, please point me to some resource so I can deepen my knowledge on javascript


I believe you misunderstand what “design flaw” means. The necessity to choose between "LOVELY" and "CUTE" inside a single function in the aforementioned example is already a problem.

One cannot overcome a poor design issues just re-writing this single function in a weird way.

Can you provide an example of a good solution please!

Can you state the problem to be solved in the first place? There is no silver bullet, nor a pill. I just stated that every single problem might be better solved without ifs.

Actually I didn’t misunderstand. I was really just having a little coding fun at your expense because I disagree with your statement. Personally, I believe that anyone that states something along the lines of “never do xyz no matter the circumstance” (not your exact words, I know) has a flawed approach to design and development. Decision/branching is a normal part of what we do. Whether you use an if statement or some other form becomes trivial in the grand scheme. I agree that it is not always the best way but equally disagree that it is always wrong.

code of conduct - report abuse