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.

--
George Hester
_______________ _______________ ____

[Lasse Reichstein Nielsen]

Re: consistency

"George Hester" <hesterloli@hot mail.com> writes:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Randy Webb]

Re: consistency

George Hester wrote:
[color=blue]
> 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:[/color]

<--snip-->
[color=blue]
> 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.[/color]

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 {}.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Andrew Thompson]

Re: consistency

On Tue, 05 Oct 2004 18:18:33 -0400, Randy Webb wrote:
[color=blue]
> ..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 {}.[/color]

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

[George Hester]

Re: consistency


"Andrew Thompson" <SeeMySites@www .invalid> wrote in message news:qghpn9mkme 89.11dptf9ue9vw w$.dlg@40tude.n et...[color=blue]
> On Tue, 05 Oct 2004 18:18:33 -0400, Randy Webb wrote:
> [color=green]
> > ..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 {}.[/color]
>
> 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[/color]

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]

Re: consistency

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message news:1xgczub3.f sf@hotpop.com.. .[color=blue]
> "George Hester" <hesterloli@hot mail.com> writes:
> [color=green]
> > 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. [/color]
>
> 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.
> [color=green]
> > 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?[/color]
>
> 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
> --
> Lasse Reichstein Nielsen - lrn@hotpop.com
> DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
> 'Faith without judgement merely degrades the spirit divine.'[/color]

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]

Re: consistency

"Lasse"

oops sorry

GH.

[Randy Webb]

Re: consistency

George Hester wrote:

<--snip-->
[color=blue]
>
>
> 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.[/color]

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.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Lasse Reichstein Nielsen]

Re: consistency

Randy Webb <HikksNotAtHome @aol.com> writes:
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> if ()
> {
>
> }
> else{
> if ()[/color]

.... 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 {
...
}
[color=blue]
> Use the brackets. It removes any and all doubts about what belongs to
> what. Otherwise, there is no way of knowing.[/color]

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.
[color=blue]
> Short of testing in every single JS engine available and seeing the
> outcomes.[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

Re: consistency

In article <ycOdndewb-QygP7cRVn-pQ@comcast.com> , Randy Webb
<HikksNotAtHome @aol.com> writes

<snip>[color=blue]
>The inconsistency comes from the lax way that JS enforces certain
>ideas, and the way browsers implement it.[/color]

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.

[color=blue]
>Personally, I *always* put my if and else's in {}, then, there is no
>inconsistenc y, no doubts, no chance of me putting something in to add
>and forgetting to add the {}.[/color]

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

John
--
John Harris

[Randy Webb]

Re: consistency

Lasse Reichstein Nielsen wrote:
[color=blue]
> Randy Webb <HikksNotAtHome @aol.com> writes:[/color]

<--snip-->
[color=blue][color=green]
>>Use the brackets. It removes any and all doubts about what belongs to
>>what. Otherwise, there is no way of knowing.[/color]
>
> 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.[/color]

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 :)
[color=blue]
>[color=green]
>>Short of testing in every single JS engine available and seeing the
>>outcomes.[/color]
>
>
> That should not be necessary unless you suspect an implementation
> of being flawed.[/color]

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 :)

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Lasse Reichstein Nielsen]

Re: consistency

Randy Webb <HikksNotAtHome @aol.com> writes:
[color=blue]
> Lasse Reichstein Nielsen wrote:[/color]
[color=blue][color=green]
>> That should not be necessary unless you suspect an implementation
>> of being flawed.[/color]
>
> 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.[/color]

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 :)
[color=blue]
> The other that comes to mind is .toFixed() in IE. Its now known to
> be flawed but that flaw was discovered by testing :)[/color]

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
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[George Hester]

Re: consistency


"John G Harris" <john@nospam.de mon.co.uk> wrote in message news:3p67ZbCFIF ZBFwjT@jgharris .demon.co.uk...[color=blue]
> In article <ycOdndewb-QygP7cRVn-pQ@comcast.com> , Randy Webb
> <HikksNotAtHome @aol.com> writes
>
> <snip>[color=green]
> >The inconsistency comes from the lax way that JS enforces certain
> >ideas, and the way browsers implement it.[/color]
>
> 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.
>
> [color=green]
> >Personally, I *always* put my if and else's in {}, then, there is no
> >inconsistenc y, no doubts, no chance of me putting something in to add
> >and forgetting to add the {}.[/color][/color]

Oh been there done that...
[color=blue]
>
> Unfortunately, some people arrange the curly brackets and indenting so
> that it's almost impossible to read correctly :-(
>
> John
> --
> John Harris[/color]

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.

--
George Hester
_______________ _______________ ____

[Andrey]

Re: consistency

George Hester wrote:
[color=blue]
> "John G Harris" <john@nospam.de mon.co.uk> wrote in message news:3p67ZbCFIF ZBFwjT@jgharris .demon.co.uk...
>[color=green]
>>In article <ycOdndewb-QygP7cRVn-pQ@comcast.com> , Randy Webb
>><HikksNotAtHo me@aol.com> writes
>>
>> <snip>
>>[color=darkred]
>>>The inconsistency comes from the lax way that JS enforces certain
>>>ideas, and the way browsers implement it.[/color]
>>
>>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.
>>
>>
>>[color=darkred]
>>>Personally , I *always* put my if and else's in {}, then, there is no
>>>inconsistenc y, no doubts, no chance of me putting something in to add
>>>and forgetting to add the {}.[/color][/color]
>
>
> Oh been there done that...
>
>[color=green]
>>Unfortunately , some people arrange the curly brackets and indenting so
>>that it's almost impossible to read correctly :-(
>>
>> John
>>--
>>John Harris[/color]
>
>
> 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.
>[/color]

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]

Re: consistency

On Thu, 07 Oct 2004 01:22:56 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com > wrote:
[color=blue]
>Randy Webb <HikksNotAtHome @aol.com> writes:[color=green]
>> The other that comes to mind is .toFixed() in IE. Its now known to
>> be flawed but that flaw was discovered by testing :)[/color]
>
>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.[/color]

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.)