Difference between if else validation methods

Question

Is there a pro or con to doing simple validation one way or another? What is the best practice? When would you use one over the other?

first method:

if ( <validate> ){
  submitForm();
} else {
  alert('Error');
    exitFn();
}

second method:

if ( !<validate> ){
  alert('Error!');
    exitFn();
}

submitForm();

I've flagged this as primarily opinion based, because I'm afraid that what this is. Coding style is just that, pure opinion & preference. One may be cleaner to me, but messy to you. Play around and stick with what you like. — N.J.Dawson, Sep 13 '16 at 09:29
Both codes work. What it boils down to is, what's easier to read and maintain? — kemicofa ghost, Sep 13 '16 at 09:30
I think it depends on execution flow of the code. If the construct does not interfere with the execution flow then the second option will be more readable. — Starx, Sep 13 '16 at 09:38

score 1 · Answer 1 · edited Sep 14 '16 at 19:40

1

if you want to exit the function in case not validated then it would be optimized

if ( !<validate> ){
  alert('Error!');
  return;
}

submitForm();

edited Sep 14 '16 at 19:40

answered Sep 13 '16 at 09:31

MKB

777
1
9
27

@torazaburo `exitFunction` would be my assumption – N.J.Dawson Sep 13 '16 at 09:32
Looks like an attempt at being descriptive about exiting a function without writing the `function x(){ ... }` and slapping a return within. I'm guessing a psuedo-code like style – N.J.Dawson Sep 13 '16 at 09:34
What's better about this form though? I don't think it's more optimized, it boils down to the same – sokkyoku Sep 13 '16 at 09:35
@torazaburo you also don't write between parenthesis for a correct conditional statement, I think you're reading too much into the snippet. – N.J.Dawson Sep 13 '16 at 09:55

sokkyoku · Answer 2 · 2016-09-13T09:57:33.000

The second method is called a guard. It's useful for delimiting a clear block of condition checking and error handling at the top of a function.

It's a common pattern which has the benefit of being recognisable to people reading your code.

It is important that guard checks leave the function if they fail, otherwise those two code blocks are not equivalent.

Example:

function a(b, c) {
    if (b.length == 0) {
        alert("can't proceed, first argument is empty");
        return;
    }
    if (c.length == 0) {
        alert("can't proceed, second argument is empty");
        return;
    }
    doFancyStuff();
}

If you were to do this in the first form it would look like this.

function a(b, c) {
    if (b.length == 0) {
        alert("can't proceed, first argument is empty");
    } else if (c.length == 0) {
        alert("can't proceed, second argument is empty");
    } else {
        doFancyStuff();
    }
}

I don't think code length is a valid argument, otherwise everyone would be golfing their code. — N.J.Dawson, Sep 13 '16 at 09:48

score 1 · Accepted Answer · edited May 23 '17 at 12:19

You're actually asking two separate questions:

In an if-then-else structure, in general should I handle error conditions first and normal flow second, or vice versa?
If I handle error conditions first, should I return after handling, or put the normal flow logic in an else block?

Both of these are matters of personal taste. Having said that, with regard to the first point, I think you would find that many programmers would put the error handling first. On the second point, opinions are split. Here is a question on this topic.

By the way, I don't know what you mean or intend with exitFn(). There is no such capability in JS.

My personal preference, and that's all it is, would be:

if ( !<validate> ) {
  alert('Error!');
  return;
}

submitForm();

The advantage here is that the error handling is usually shorter and it's better to get it out of the way as soon as possible, rather than force someone reading your code to go down a dozen or two dozen lines to see how (or if) errors are being handled; also, putting the normal flow within the if will add an extra level of indenting.

As someone mentioned, it's meant to signal doing any other operations then returning out of function. I figured people would read it as pseudo-code since there is also no ! capability in javascript. Thanks for the clear logic and rephrasing the question. — Shen Adrien, Sep 14 '16 at 17:54

score 0 · Answer 4 · edited Sep 13 '16 at 09:54

0

Generally, it would depend on the context - it can be useful to rely on an 'if' on its own if you're just processing a string, but it is better to handle a more boolean function by capturing both results. Any situation where you have an 'else' or an 'else if' (for multiple conditions) means you're filtering more reliably, rather than just rejecting an input

I'm not sure I'd feel comfortable with the second example, but that might just be down to how I've been conditioned with regards to conditional statements.

It does strike me as a matter of opinion, rather than anything strictly right/wrong.

edited Sep 13 '16 at 09:54

answered Sep 13 '16 at 09:44

Chris J

1,441
9
19

What is "more boolean"? – Sep 14 '16 at 19:38
A function that relies on pure true/false outcomes, rather than ones which are individually true/false, but not collectively (hence 'both results' in the context, rather than 'all results'). – Chris J Sep 14 '16 at 20:15

Difference between if else validation methods

4 Answers4