consistency

[George Hester]

In JavaScript we have the if then else which, if there is not more than one statement following we do not need to use {}. For example:

if ()
;

works fine and so does

if ()
if()
;
else
;

But what if we want the else to apply to the parent if?

if ()
if ()
;
else
;

Here we see that only one JavaScript statement follows after each if and else. But we are in a position that JavaScript is going to apply the else to the child if. We are required then to do this:

if (){
if ()
;
}
else
;

even though the parent if has only one JavaScript statement following. This is inconsistent isn't it? It's not a
problem it's just that I don't like inconsistency unless there is a valid explanation for the inconsistency based
on the rules of JavaSxript. Is there? Thanks.

 

[Lasse Reichstein Nielsen]

if ()
if()
;
else
;

But what if we want the else to apply to the parent if?

if ()
if ()
;
else
;

Here we see that only one JavaScript statement follows after each if
and else. But we are in a position that JavaScript is going to
apply the else to the child if.

Correct.
Notice that the first ";" doesn't terminate the "if" statement, but
the inner (then branch) statement of that "if" statement. It would
give the same result to write
---
if ()
if ()
{}
else
{}
---

The problem (if one can call it that) is common to all programming
languages with optional "else" branches and without an explicit
"end-if" marker. That includes all languages derived from the C
syntax.

We are required then to do this:

if (){
if ()
;
}
else
;

even though the parent if has only one JavaScript statement
following. This is inconsistent isn't it?

Not really. Compare it to subtraction. If you write 4-3, it gives 1.
If you write 6-1, it gives 5. However, if you write 6-4-3, it doesn't
give 5. You need to add parentheses to show how you want it to
associate to get the result of 6-(4-3), because there are two ways to
associate 6-4-3, and the compiler picks one of them. If you want the
other one, you need to add explicit grouping (in an expression, you
use parentheses).

Likewise
if (expr1) if (expr2) stmt1 else stmt2
can be understood in two ways:
if (expr1) { if (expr2) stmt1 else stmt2 }
and
if (expr1) { if (expr2) stmt1 } else stmt2

The compiler defaults to the first. If you want the second, you have
to add explicit grouping (with statments, you use curly braces).

/L

 

[Randy Webb]

In JavaScript we have the if then else which, if there is not more
than one statement following we do not need to use {}. For example:

even though the parent if has only one JavaScript statement following.
This is inconsistent isn't it? It's not a problem it's just that I don't
like inconsistency unless there is a valid explanation for the inconsistency
based on the rules of JavaSxript. Is there? Thanks.

The inconsistency comes from the lax way that JS enforces certain ideas,
and the way browsers implement it. Personally, I *always* put my if and
else's in {}, then, there is no inconsistency, no doubts, no chance of
me putting something in to add and forgetting to add the {}.

 

[George Hester]

There was a situation discussed on another group recently
that had the OP in an interview, being asked for their
interpretation of a particularly obtuse piece of code.

After a split second they commented they'd rewirte it
so it was clear. They got the job.

The panel wanted to hear the applicant was more concerned with
readable, maintainable code, than interpreting the arcane
details of operator precedence in the interview example.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

Not sure what you are referring to but I guess this does it:

if ()
if ()
;
else
;
else
;

So if we want:

if ()
if ()
;
else
;

without the brackets then we have to do it as I showed above. That's fine. Thanks for the input.

George Hester
__________________________________

 

[George Hester]

Correct.
Notice that the first ";" doesn't terminate the "if" statement, but
the inner (then branch) statement of that "if" statement. It would
give the same result to write
---
if ()
if ()
{}
else
{}
---

The problem (if one can call it that) is common to all programming
languages with optional "else" branches and without an explicit
"end-if" marker. That includes all languages derived from the C
syntax.


Not really. Compare it to subtraction. If you write 4-3, it gives 1.
If you write 6-1, it gives 5. However, if you write 6-4-3, it doesn't
give 5. You need to add parentheses to show how you want it to
associate to get the result of 6-(4-3), because there are two ways to
associate 6-4-3, and the compiler picks one of them. If you want the
other one, you need to add explicit grouping (in an expression, you
use parentheses).

Likewise
if (expr1) if (expr2) stmt1 else stmt2
can be understood in two ways:
if (expr1) { if (expr2) stmt1 else stmt2 }
and
if (expr1) { if (expr2) stmt1 } else stmt2

The compiler defaults to the first. If you want the second, you have
to add explicit grouping (with statments, you use curly braces).

/L

Yes Lassie I like to use operator precedence when I can. I know the use of {} and () helps to "read" the code
but it isn't really reading that I am interested. I'm interested in how the compiler works.

Your 6-4-3. Let's try this:

6-4-3*2

Here since multiplication is left to right and it applies before add we get

6-4-6

resulting in -4

and not -2.

Thanks It is the associative rules of JavaScript and that explains it. I always get a kick out of things like this:

2*-4. I know the () around the -4 aren't necessary it just feels like it.

George Hester
__________________________________

 

[George Hester]

"Lasse"

oops sorry

GH.

 

[Randy Webb]

George Hester wrote:

Not sure what you are referring to but I guess this does it:

if ()
if ()
;
else
;
else
;

So if we want:

if ()
if ()
;
else
;

without the brackets then we have to do it as I showed above. That's fine. Thanks for the input.

It is not the else and the spacing that does it. what makes code clear,
concise and unmistakable (in if/else statements) are the brackets.

if ()
{

}
else{
if ()
{
}
else
{
}
}

Use the brackets. It removes any and all doubts about what belongs to
what. Otherwise, there is no way of knowing. Short of testing in every
single JS engine available and seeing the outcomes. With the brackets,
it becomes moot.

 

[Lasse Reichstein Nielsen]

It is not the else and the spacing that does it. what makes code
clear, concise and unmistakable (in if/else statements) are the
brackets.

I agree with that. Having spent time trying to find a bug that turned
out to be a two-line else branch with no brackets (but nicely
indented), I recommend *always* using them.

if ()
{

}
else{
if ()

.... however in just this case I make an exception. The "else-if"
construction is itself so easily recognizable that I just write:

if (...) {
...
} else if (...) {
...
} else {
...
}

Use the brackets. It removes any and all doubts about what belongs to
what. Otherwise, there is no way of knowing.

Sure three is. The grammar of Javascript/ECMAScript(/C/C++/Java/etc)
is quite clear. In the case of an ambiguity, the else binds to the
closest if that it can match.

Short of testing in every single JS engine available and seeing the
outcomes.

That should not be necessary unless you suspect an implementation
of being flawed.

/L

 

[John G Harris]

The inconsistency comes from the lax way that JS enforces certain
ideas, and the way browsers implement it.

No, it's not inconsistent or lax. What it is, is that
if then if then else
is inherently ambiguous. You can't guess which 'then' the programmer
attached the 'else' to.

Javascript solves this problem by specifying which guess the interpreter
*must* make. So does Java, C++, C, Pascal, and, I believe, Algol 60.

Personally, I *always* put my if and else's in {}, then, there is no
inconsistency, no doubts, no chance of me putting something in to add
and forgetting to add the {}.

Unfortunately, some people arrange the curly brackets and indenting so
that it's almost impossible to read correctly :-(

John

 

[Randy Webb]

Sure three is. The grammar of Javascript/ECMAScript(/C/C++/Java/etc)
is quite clear. In the case of an ambiguity, the else binds to the
closest if that it can match.

Thats assuming that all JS engines follow ECMA to the letter, and I
don't know of one that does. But, my own personal opinion of ECMA skews
my thoughs about them It's a good theory about the way things should
be, but not a good example of how things really are. .toFixed in IE
being a very good example of it. But the converse is also true.

Flip a coin

That should not be necessary unless you suspect an implementation
of being flawed.

Typically, I would agree with that. But a thread awhile back comes to
mind, where it was discussed of how to know, for sure, that changing the
..innerHTML property of an element actually changed it's visible
appearance. The only way to know for sure is to test it and see for
yourself. Otherwise you have to assume that it "works", and thats not
always a good idea. Whether you suspect a flawed implementation or not.
The other that comes to mind is .toFixed() in IE. Its now known to be
flawed but that flaw was discovered by testing

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

Typically, I would agree with that. But a thread awhile back comes to
mind, where it was discussed of how to know, for sure, that changing
the .innerHTML property of an element actually changed it's visible
appearance.

There is a very clear distinction between the reliablilty of the core
Javascript (i.e., ECMAScript) vs the DOM. ALmost any DOM feature is
implemented differetly in some actualy browser. The core language
is almost exactly alike among all browsers that claim to support
the same version of ECMAScript. If there are bugs, they are ususally
in obscure corners of the language. IE's toFixed problem is pretty
much the exception the proves the rule

The other that comes to mind is .toFixed() in IE. Its now known to
be flawed but that flaw was discovered by testing

I doubt that it was found by testing for it. More likely, some other
use of it gave unexpected results, and debugging pointed out that
toFixed gave odd answers. *Then* it was tested, but only because
it was already believed to be flawed.

Something as high profile as the association of "else" is unlikely
to have had a surviving bug for long.

/L

 

[George Hester]

No, it's not inconsistent or lax. What it is, is that
if then if then else
is inherently ambiguous. You can't guess which 'then' the programmer
attached the 'else' to.

Javascript solves this problem by specifying which guess the interpreter
*must* make. So does Java, C++, C, Pascal, and, I believe, Algol 60.

Oh been there done that...

Unfortunately, some people arrange the curly brackets and indenting so
that it's almost impossible to read correctly :-(

John

Hi John:

Well I'll have you know I just scratched that whole section of the code. Yes I know

if ()
if ()
;
else
;

is ambiguous. That's why I asked about it. It turns out I could just add a dummy else

if ()
if ()
;
else //the dummy else
;
else
;

and that would have removed the ambiguity. But as it turns out I changed to the:

()?:;

works better anyway. Do you happen to know what ()?:; is called? I tried googling on "inline logical test" but came up empty-handed.

As far as readability and {} is concerned well taken. The only reason I may not do it (besides experimentally) is reduce the size of the file.

 

[Andrey]

Oh been there done that...




Hi John:

Well I'll have you know I just scratched that whole section of the code. Yes I know

if ()
if ()
;
else
;

is ambiguous. That's why I asked about it. It turns out I could just add a dummy else

if ()
if ()
;
else //the dummy else
;
else
;

and that would have removed the ambiguity. But as it turns out I changed to the:

()?:;

works better anyway. Do you happen to know what ()?:; is called? I tried googling on "inline logical test" but came up empty-handed.

As far as readability and {} is concerned well taken. The only reason I may not do it (besides experimentally) is reduce the size of the file.

Hi George,

According to the C# book operator ()?:; is in fact operator ? with a specific syntax.
And ... it's called "ternary operator", because it requires three operands .. (quote from the same
book).

I didn't take part in this fun topic, but just wonder why you got curious about "if-else"
consistency just in javascript? Did you ever use c++/Java/Pascal/<almost any other language>
They all are the same story... And i think it's not inconsistency in any way - just a rule you'd follow.

BR
Andrey

 

[Jim Ley]

I doubt that it was found by testing for it. More likely, some other
use of it gave unexpected results, and debugging pointed out that
toFixed gave odd answers.

I found it when testing the toFixed type routines for the javascript
FAQ, and finding the routines reporting wrong for the range, so in a
way it was testing that found it for me! (I doubt I found it first, or
that it was unknown in the group before I found it etc.)

 

[Michael Winter]

[snip]

Do you happen to know what ()?:; is called?

In Javascript, it's referred to as the "Conditional Operator". As another
poster pointed out, it has other names in other languages.

[snip]

Mike


Please trim.

 

[George Hester]

Hi George,

According to the C# book operator ()?:; is in fact operator ? with a specific syntax.
And ... it's called "ternary operator", because it requires three operands .. (quote from the same
book).

I didn't take part in this fun topic, but just wonder why you got curious about "if-else"
consistency just in javascript? Did you ever use c++/Java/Pascal/<almost any other language>
They all are the same story... And i think it's not inconsistency in any way - just a rule you'd follow.

BR
Andrey

dabbled in those languages would be more like it. I'm not so modern. When I was in school FORTRAN was all the rage. And a PC was very dumb. I'm not really that old it's just that I was in school at the tail end of procedure languages. Pascal was for the Business majors (and COBOL) but we were doing numerical methods and so FORTRAN (not free form).

I got curious because I always omit the {} when they are not needed. And when I didn't care about the child if's else only the parent if's else I started babbling. Sorry I should have realized it.

"ternary operator" yes thank you.

 

[Lasse Reichstein Nielsen]

According to the C# book operator ()?:; is in fact operator ? with a
specific syntax.

The ?: operator (the parenthese are not needed, and the semicolon is
not even part of the same expression) can be characterized in different
ways. I usually see it represented as one operator in itself, not
a "?" operator with a special syntax containing ":".

And ... it's called "ternary operator", because it requires three
operands .. (quote from the same book).

That is not it's name, though, merely a descriptive term.

As you say, it's called a "terary" operator because it takes three
operands, just as "+" and "-" are called binary operators and "!"
and "~" are unary operators.

Since it is the *only* ternary operator in the language (and in all
the C-derived languages), it is also mentioned as *the* ternary
operator.

"The C# Programming Language" calls it "the conditional operator",
and mentions that it is sometimes called "the ternary operator".

"The C Programming Language, 2nd edition" says: