By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
460,036 Members | 978 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 460,036 IT Pros & Developers. It's quick & easy.

How optimized ar eif-statements in JS

P: n/a
In the code at our company i see the following.

if (someStuff != null) {
if (someStuff != "") {
doThatThing ();
}
}

While it's fully correct and valid, i'd like to rewrite it
as follows.

if (someStuff != null && someStuff != "")
doThatThing ();

I know that some languages will evaluate the first condition
of the conjunction and, provided that it fails, conclude
that the statement is not to be performed. I'd like to
assume so in this case as well, but wishing not to show
arrogance and know-better-ism, i'd like to check with more
experienced programmers first.

Will JS evaluate the whole konjunction or will it be
intelligent enough to stop as the first partial condition
fails? Is it depending on the platform used?

--
Regards
Konrad Viltersten
Jun 27 '08 #1
Share this Question
Share on Google+
21 Replies


P: n/a
K Viltersten escribió:
if (someStuff != null && someStuff != "")
[...]
Will JS evaluate the whole konjunction or will it be
intelligent enough to stop as the first partial condition
fails? Is it depending on the platform used?
It'll stop as soon as it has a definitive result:

http://developer.mozilla.org/en/docs...ical_Operators

See the "Short-Circuit Evaluation" header.

--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--
Jun 27 '08 #2

P: n/a
On May 22, 9:46 am, K Viltersten wrote:
In the code at our company i see the following.

if (someStuff != null) {
if (someStuff != "") {
doThatThing ();
}

}

While it's fully correct and valid, i'd like to rewrite it
as follows.

if (someStuff != null && someStuff != "")
doThatThing ();
It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches. It is extremely common to have a
single statement conditionally executed and then to realise that a
second statement will need to be added to that branch. With the braces
already in place all you do is add the statement, but without the
braces you often get fooled by the indentation into adding the
statement at the existing level of indentation and not seeing that
only one statement is going to conditionally executed and any that
follow it will be unconditionally executed. The usual result is a
confusing and hard to track down bug.
I know that some languages will evaluate the first
condition of the conjunction and, provided that it
fails, conclude that the statement is not to be
performed. I'd like to assume so in this case as
well, but wishing not to show arrogance and
know-better-ism, i'd like to check with more
experienced programmers first.

Will JS evaluate the whole konjunction or will it
be intelligent enough to stop as the first partial
condition fails? Is it depending on the platform
used?
The language specification requires short circuiting, and no
implementations have been observed to fail to correctly implement the
specification in this regard.

However, your simplification looks like it probably still falls short
of an optimum outcome. The first test, - someStuff != null -, will be
false for null and undefined values, so those two values are excluded
by the first test. The second test, - someStuff != "" -, will be false
for boolean false, numeric zero and empty strings. So the values that
can pass the combined test are all[*1] objects (including functions),
non-zero numbers (including NaN), non-empty strings, and boolean true.

[*1] Actually not all objects will pass the - someStuff != "" - test
because the comparison with a string implies type-conversion so an
object with a - toString - method that returned the empty string would
be equal to the empty string primitive. That is -
alert({toString:function(){return '';}} == ''); - alerts "true".

An alternative test could be:-

if(someStuff){
doThatThing ();
}

- where the value of - someStruff - is implicitly type-converted to
boolean and since the empty string, boolean false, numeric zero and
NaN, the undefined value and null all type-convert to boolean false
the only practical differences between that test and your previous one
is that the NaN numeric value will not pass the test (which is
probably a good idea) and that all objects would pass regardless of
how they type-convert to primitive values. While the type-converting
to boolean test is shorter simpler and faster than the original (which
includes at least one implicit type-conversion to boolean anyway).
Jun 27 '08 #3

P: n/a
>In the code at our company i see the following.
>>
if (someStuff != null) {
if (someStuff != "") {
doThatThing ();
}
}

While it's fully correct and valid, i'd like to rewrite it
as follows.

if (someStuff != null && someStuff != "")
doThatThing ();

It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches. It is extremely common to have a
single statement conditionally executed and then to realise that a
second statement will need to be added to that branch. With the braces
already in place all you do is add the statement, but without the
braces you often get fooled by the indentation into adding the
statement at the existing level of indentation and not seeing that
only one statement is going to conditionally executed and any that
follow it will be unconditionally executed. The usual result is a
confusing and hard to track down bug.
I forgot to add the braces, otherwise i'm always putting
them in by copmany requirement. The extra pointers and
suggestions are ALWAYS appreciated, of course. Thanks!

With risk of getting into something very nasty - the
argument about braces "already there when one needs them"
doesn't hold, in my opinion.

1. At some point of time one needs to put them in so
if it happens frequently that one'll need to put more
things there, it's not MORE work to do so. At best,
not much less (or much less, when lucky).

2. Unless one isn't a hard-core-never-seen-anything-else
Python programmer, one shouldn't confuse indentation and
scoping. At least i've never had that problem but perhaps
i'm a genius, i can admit. :)

Please enlighten me if i'm missing anything and please
keep in mind that the above are only my personal views,
hence subject to change, if needed.
>Will JS evaluate the whole konjunction or will it
be intelligent enough to stop as the first partial
condition fails? Is it depending on the platform
used?

The language specification requires short circuiting, andno
implementations have been observed to fail to correctlyimplement the
specification in this regard.

However, your simplification looks like it probably stillfalls short of
an optimum outcome.
<snippage>
An alternative test could be:

if (someStuff) { doThatThing (); }
To be perfectly sure i got it right - i can skip the test
in the original post and simply test "is someStuff the
case"?! That would be awsomely simplifying! In fact, that
could just make me appreciate JavaScript, hehe. :)

--
Regards
Konrad Viltersten
Jun 27 '08 #4

P: n/a
rf
Henry <rc*******@raindrop.co.ukwrote in news:18129482-c1c5-4d41-888e-
88**********@d77g2000hsb.googlegroups.com:
>if (someStuff != null && someStuff != "")
doThatThing ();
It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches.
Bullshit.

--
Richard
Killing all google groups posts
The Usenet Improvement Project: http://improve-usenet.org
Jun 27 '08 #5

P: n/a
On May 22, 1:47 pm, rf wrote:
Henry wrote in news:18 ... @d77g2000hsb.googlegroups.com:
^^^^^^^^^^^^ ^^^
>
>>if (someStuff != null && someStuff != "")
doThatThing ();
It is very widely considered good style when writing
javascript to never omit the braces of a block statement
from around the code executed in - if/else - branches.

Bullshit.
<snip>
Killing all google groups posts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hypocrisy.
Jun 27 '08 #6

P: n/a
rf meinte:
Henry
>It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches.

Bullshit.
Since I always do it the way recommeneded by Richard, I'm sure you can
elaborate on that.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jun 27 '08 #7

P: n/a
On May 22, 1:35 pm, K Viltersten wrote:
>>In the code at our company i see the following.
>>if (someStuff != null) {
if (someStuff != "") {
doThatThing ();
}
}
>>While it's fully correct and valid, i'd like to rewrite it
as follows.
>>if (someStuff != null && someStuff != "")
doThatThing ();
>It is very widely considered good style when writing
javascript to never omit the braces of a block statement
from around the code executed in - if/else - branches.
It is extremely common to have a single statement
conditionally executed and then to realise that a second
statement will need to be added to that branch. With the
braces already in place all you do is add the statement,
but without the braces you often get fooled by the
indentation into adding the statement at the existing
level of indentation and not seeing that only one statement
is going to conditionally executed and any that follow it
will be unconditionally executed. The usual result is a
confusing and hard to track down bug.

I forgot to add the braces, otherwise i'm always putting
them in by copmany requirement. The extra pointers and
suggestions are ALWAYS appreciated, of course. Thanks!

With risk of getting into something very nasty - the
argument about braces "already there when one needs them"
doesn't hold, in my opinion.

1. At some point of time one needs to put them in so
if it happens frequently that one'll need to put more
things there, it's not MORE work to do so. At best,
not much less (or much less, when lucky).
The amount of work isn't really the point. It is about avoiding
introducing bugs. There is a very high correlation between the use of
braces in javascript source code and (sensible) indentation, such that
it becomes very easy to see indentation and mentally imply the braces.
Most of the time that would not be a problem because there braces
would actually be there, and so that re-enforces the subconscious
assumption that they will be there. And so on the relatively rare
occasions were there is indentation without braces it becomes very
easy to make the addition to the indented code and never observe that
there were no braces around it.
2. Unless one isn't a hard-core-never-seen-anything-else
Python programmer, one shouldn't confuse indentation and
scoping.
Javascript is not block scoped so indentation and scoping are not that
related most of time.
At least i've never had that problem but perhaps
i'm a genius, i can admit. :)
But didn't you say that you would normally include the braces by
"company requirement"? That means you will not have much opportunity
to make the mistakes that occur when they are missing.
Please enlighten me if i'm missing anything and please
keep in mind that the above are only my personal views,
hence subject to change, if needed.
If all else fails time will enlighten you.
>>Will JS evaluate the whole konjunction or will it
be intelligent enough to stop as the first partial
condition fails? Is it depending on the platform
used?
>The language specification requires short circuiting, andno
implementations have been observed to fail to correctlyimplement
the specification in this regard.
>However, your simplification looks like it probably stillfalls
short of an optimum outcome.
<snippage>
An alternative test could be:
>if (someStuff) { doThatThing (); }

To be perfectly sure i got it right - i can skip the test
in the original post and simply test "is someStuff the
case"?!
The test is more 'does someStuff's value have truness', but if that is
the discrimination that fits the situation (and it certainly appears
to be from the incomplete fragment posted) then the simpler test will
do the job.
That would be awsomely simplifying!
Where does this go in the next decade? If simple things are already
being ladled as awe inspiring what superlatives are going to be left
for the things that are really worth pointing out?
In fact, that
could just make me appreciate JavaScript, hehe. :)
Jun 27 '08 #8

P: n/a
rf
Henry <rc*******@raindrop.co.ukwrote in news:fb90e2f3-c5c9-41bb-a794-
13**********@w7g2000hsa.googlegroups.com:
On May 22, 1:47 pm, rf wrote:
>Henry wrote in news:18 ... @d77g2000hsb.googlegroups.com:
^^^^^^^^^^^^ ^^^
>>
>>>if (someStuff != null && someStuff != "")
doThatThing ();
It is very widely considered good style when writing
javascript to never omit the braces of a block statement
from around the code executed in - if/else - branches.

Bullshit.
<snip>
>Killing all google groups posts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hypocrisy.
I delve in now and again, just to see what the supid bloody buggers are up
to. This one I could not resist replying to as it has no foundation at all.

I also can't be arsed to change my sig just for the occasional foray.

--
Richard
Killing all google groups posts
The Usenet Improvement Project: http://improve-usenet.org
Jun 27 '08 #9

P: n/a
rf wrote:
Henry wrote:
>rf wrote:
>>Henry wrote:
<snip>
>>>It is very widely considered good style when writing
javascript to never omit the braces of a block statement
from around the code executed in - if/else - branches.
>>Bullshit.
<snip>
This one I could not resist replying to as it has no
foundation at all.
In "javascript:The Good Parts", Douglass Crockford writes:" An if or
while or do or for statement can take a block or a single statement.
The single statement form is another attractive nuisance. It offers
the advantage of saving two characters, a dubious advantage. It
obscures the program's structure so that subsequent manipulators of
the code can easily insert bugs." (and unsurprisingly JSLint will not
pass code that omits the braces).

My assertion that "It is very widely considered good style ..." is not
without foundation.
Jun 27 '08 #10

P: n/a
>I forgot to add the braces, otherwise i'm always putting
>them in by copmany requirement. The extra pointers and
suggestions are ALWAYS appreciated, of course. Thanks!

With risk of getting into something very nasty - the
argument about braces "already there when one needs them"
doesn't hold, in my opinion.

1. At some point of time one needs to put them in so
if it happens frequently that one'll need to put more
things there, it's not MORE work to do so. At best,
not much less (or much less, when lucky).

The amount of work isn't really the point. It is about avoiding
introducing bugs. There is a very high correlation between the use of
braces in javascript source code and (sensible) indentation, such that
it becomes very easy to see indentation and mentally imply the braces.
Most of the time that would not be a problem because there braces
would actually be there, and so that re-enforces the subconscious
assumption that they will be there. And so on the relatively rare
occasions were there is indentation without braces it becomes very
easy to make the addition to the indented code and never observe that
there were no braces around it.
In my experience (not JS-related, of course but still from
programming), the bugs are not so commonly introduced due
to that. Also, i find it's not very rare at all to have
one line long statements. In fact, in my case, it seems to
be rather common. Please note, it's my personal opinion
only and i haven't proof/disproof either way. I'm not
claiming you're wrong. I'm saying that i don't recognize
the case from MY experience, hence being careful.
>2. Unless one isn't a hard-core-never-seen-anything-else
Python programmer, one shouldn't confuse indentation and
scoping.

Javascript is not block scoped so indentation and scopingare not that
related most of time.
The point was that by seeing an indentation made nicely, i
never had any errors introduced by forgetting the braces.
But didn't you say that you would normally include thebraces by "company
requirement"? That means you will nothave much opportunity to make the
mistakes that occur whenthey are missing.
I won't have problems with polar bears either. Neither is
due to the coding standard i'm following, however. I can't
remember a single occasion when i've forgot to add braces
when needed... My opinion is that it's an urban legend but,
let me remind, i might be mistaken.
>Please enlighten me if i'm missing anything and please
keep in mind that the above are only my personal views,
hence subject to change, if needed.

If all else fails time will enlighten you.
I see somebody else responded by reference to fornicates
of the cowly type. It wasn't me and since i'm sensing a
bit of irritation, i'm suggesting to drop the subject. :)
Where does this go in the next decade? If simple things are already
being ladled as awe inspiring what superlatives are going to be left
for the things that are really worth pointing out?
I've checked Wikipedia for "universal judge of what's
simple thing" but sadly they haven't updated the database
with your name yet, so let's just say that what's "simple
thing" to you, perhaps is a new concept to someone else.

I'm here to ask questions and learn. Not to get insulted!
I'm thankful for the advices and suggestions you (and
others) are offering but that doesn't entitle you to be
impolite or deminishing. I can be that too. I choose not
to and i'd appreciate if others could follow. Thank you.

--
Regards
Konrad Viltersten
Jun 27 '08 #11

P: n/a
On May 22, 8:47*am, rf <r...@x.invalidwrote:
Henry <rcornf...@raindrop.co.ukwrote in news:18129482-c1c5-4d41-888e-
888d1ebe1...@d77g2000hsb.googlegroups.com:
if (someStuff != null && someStuff != "")
* *doThatThing ();
It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches.

Bullshit.

--
Richard
Killing all google groups posts
The Usenet Improvement Project:http://improve-usenet.org
lol... you read my mind!
Jun 27 '08 #12

P: n/a
Henry wrote:
On May 22, 9:46 am, K Viltersten wrote:
>In the code at our company i see the following.

if (someStuff != null) {
if (someStuff != "") {
doThatThing ();
}

}

While it's fully correct and valid, i'd like to rewrite it
as follows.

if (someStuff != null && someStuff != "")
doThatThing ();

It is very widely considered good style when writing javascript to
never omit the braces of a block statement from around the code
executed in - if/else - branches.
I think I know what you mean and I concur as for if-else; however, it
should be noted that there is no block statement if there are no braces.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Jun 27 '08 #13

P: n/a
On May 22, 3:10 pm, K Viltersten wrote:
<snip>
>>With risk of getting into something very nasty - the
argument about braces "already there when one needs them"
doesn't hold, in my opinion.
>>1. At some point of time one needs to put them in so
if it happens frequently that one'll need to put more
things there, it's not MORE work to do so. At best,
not much less (or much less, when lucky).
>The amount of work isn't really the point. It is about
avoiding introducing bugs. There is a very high correlation
between the use of braces in javascript source code and
(sensible) indentation, such that it becomes very easy
to see indentation and mentally imply the braces. Most
of the time that would not be a problem because there
braces would actually be there, and so that re-enforces
the subconscious assumption that they will be there. And
so on the relatively rare occasions were there is
indentation without braces it becomes very easy to make
the addition to the indented code and never observe that
there were no braces around it.

In my experience (not JS-related, of course but still from
programming), the bugs are not so commonly introduced due
to that.
<snip>

And in my JS related experience (and I did explicitly qualify the
recommendation with "when writing javascript") bugs of that type are
sufficiently commonly introduced that it is worth having a formal
practice that avoids them.

<snip>
>>Please enlighten me if i'm missing anything and please
keep in mind that the above are only my personal views,
hence subject to change, if needed.
>If all else fails time will enlighten you.

I see somebody else responded by reference to fornicates
of the cowly type.
But nothing tangible supporting that assertion.
It wasn't me and since i'm sensing a
bit of irritation, i'm suggesting to drop the subject. :)
>Where does this go in the next decade? If simple things
are already being ladled as awe inspiring what superlatives
are going to be left for the things that are really worth
pointing out?

I've checked Wikipedia for "universal judge of what's
simple thing"
Why? There is no universal judgment involved, just a judgement of the
relative simplicity/complexity of aspects of a single programming
language.
but sadly they haven't updated the database
with your name yet, so let's just say that what's "simple
thing" to you, perhaps is a new concept to someone else.
A concepts being new does not preclude the possibility that it is also
simple.
I'm here to ask questions and learn. Not to get insulted!
What insult? I am just worried about your health; if you react to
javascript's type-conversion rules with awe you will have died of
shock before you stand a chance of understanding its closures.
I'm thankful for the advices and suggestions you (and
others) are offering but that doesn't entitle you to be
impolite or deminishing. I can be that too. I choose not
to and i'd appreciate if others could follow. Thank you.
There is no point in trying to dictate here.
Jun 27 '08 #14

P: n/a
>In my experience (not JS-related, of course but still from
>programming), the bugs are not so commonly introduced due
to that.
<snip>

And in my JS related experience (and I did explicitly qualify the
recommendation with "when writing javascript") bugs of that type are
sufficiently commonly introduced that it is worth having a formal
practice that avoids them.
If you say so. My limited experience doesn't let me
discuss the subject. Not saying i agree, though. :)
>I see somebody else responded by reference to fornicates
of the cowly type.

But nothing tangible supporting that assertion.
Yes, the post was rather short. Nevertheless, my point
was that i didn't say that so any ennoyance due to that,
need to be taken elsewhere. Otherwise we run the risk of
me starting to use that language as well and that's not
a flathering scenario.
>I've checked Wikipedia for "universal judge of what's
simple thing"

Why? There is no universal judgment involved, just ajudgement of the
relative simplicity/complexity of aspectsof a single programming
language.
I don't agree. "It is simple" is universal. "According to me,
it is simple", would be more humble and appropriate, in my
opinion. After all, it was only an opinion, right?
>but sadly they haven't updated the database
with your name yet, so let's just say that what's "simple
thing" to you, perhaps is a new concept to someone else.

A concepts being new does not preclude the possibility thatit is also
simple.
It doesn't imply that either. In this case, it was new AND
difficult. To me, that is.
>I'm here to ask questions and learn. Not to get insulted!

What insult?
If i state X is difficult for me and you claim "no, it's
easy" (as opposed to "to me, it's easy") then you do
insult my capabilities. That's how i feel.
I am just worried about your health; if you react to
javascript's type-conversion rules with awe you will have died of
shock before you stand a chance of understanding its closures.
I seriously doubt that you care about my condition. Nor do
you believe in me going to die because of that, i think.
>I'm thankful for the advices and suggestions you (and
others) are offering but that doesn't entitle you to be
impolite or deminishing. I can be that too. I choose not
to and i'd appreciate if others could follow. Thank you.

There is no point in trying to dictate here.
I expressed thankfulness and asked for something i'd
appreciate. That's hardly dictating, in my view but
if you took it that way, please accept my appology.

--
Regards
Konrad Viltersten
Jun 27 '08 #15

P: n/a
>I believe it's far finer and harder to always be polite and mature
>on Usenet but that's my standards. Not all follow them, sadly.

So much for that.
Yes. Agreed.
>As for the being tough on the Usenet, please see this image. I
always take a look at it when feeling like responding "toughly".

It is about reading toughly, not replying.
>http://www.uberh4x0r.org/~lethalp1mp...nny/retard.jpg

After i've taken a look at that image, i ALWAYS loose my steam
and reword my reply. I don't want to be that "tough on Usenet". :)

This is not funny (or relevant).
I disagree but i'm sorry if it offended you. My mistake.
Score adjusted
What score?

--
Regards
Konrad Viltersten
Jun 27 '08 #16

P: n/a
On Thu, 22 May 2008 at 06:36:59, in comp.lang.javascript, Henry wrote:

<snip>
>In "javascript:The Good Parts", Douglass Crockford writes:" An if or
while or do or for statement can take a block or a single statement.
I'm surprised he says that. It shows a surprising lack of knowledge.

The condition part of an if statement is followed by exactly one
statement. A block statement is just as much exactly one statement as is
a return statement or an expression statement.

The same is also true in Algol, Pascal, C, C++, Java, and C# so there's
not much excuse for not understanding this.

>The single statement form is another attractive nuisance. It offers
the advantage of saving two characters, a dubious advantage. It
obscures the program's structure so that subsequent manipulators of
the code can easily insert bugs."
It's a matter of taste and common sense. If curly brackets are hidden
away so it's difficult to notice them then obviously people risk not
noticing when they're absent.

On the other hand, if a block statement looks like a distinct statement,
which it is, then its absence will be noticed :

if (a < 0)
b = 2;

if (a < 0)
{
b = 2;
c = 4;
}

>(and unsurprisingly JSLint will not
pass code that omits the braces).
It's a good rule if you hire programmers who are untidy, sloppy, and
don't really know what they are doing.

Otherwise, it hides the structure of the program and is rather
insulting.

>My assertion that "It is very widely considered good style ..." is not
without foundation.
A lot of things are very widely considered good - eval and monster
libraries for instance - but they aren't. Here, it's not bad but anyone
who says it's the one true way is wrong and a loudmouth.

John
--
John Harris
Jun 27 '08 #17

P: n/a
On May 23, 12:13 pm, John G Harris wrote:
Henry wrote:
<snip>
>In "javascript:The Good Parts", Douglass Crockford writes:
"An if or while or do or for statement can take a block or
a single statement.

I'm surprised he says that. It shows a surprising lack of
knowledge.
I don't think that the wording is the result of a lack of knowledge,
but rather a questionable decision about where to pitch the style of
explanation.

<snip>
>The single statement form is another attractive nuisance.
It offers the advantage of saving two characters, a
dubious advantage. It obscures the program's structure so
that subsequent manipulators of the code can easily
insert bugs."

It's a matter of taste and common sense.
As is almost always the case with coding style decisions.
If curly brackets are hidden away so it's difficult to
notice them then obviously people risk not noticing when
they're absent.

On the other hand, if a block statement looks like a distinct
statement, which it is,
It is difficult to see how a statement that contains other statements
can ever look like a distinct statement.
then its absence will be noticed :

if (a < 0)
b = 2;

if (a < 0)
{
b = 2;
c = 4;
}
The appearance of code fragments in isolation may not reflect the
impact of different formal formatting decisions in the context of real
code (where there will likely be code before and after those fragments
that impacts on their readability).
>(and unsurprisingly JSLint will not
pass code that omits the braces).

It's a good rule if you hire programmers who are untidy,
sloppy, and don't really know what they are doing.

Otherwise, it hides the structure of the program and
is rather insulting.
How does it hide the structure of the program? You go from a situation
of having indentation showing the structure to having indentation and
braces showing the structure, that should make the structure more
obvious.
>My assertion that "It is very widely considered good
style ..." is not without foundation.

A lot of things are very widely considered good - eval and
monster libraries for instance - but they aren't.
And disputing whether the thing that is 'widely considered' is correct
or not is not the same as disputing whether it is 'widely considered'
or not.

Douglass Crockford has probably had more influence on people's beliefs
about javascript style rules than any other individual (largely
thought authoring JSLint). As a result any of his rules are 'widely
considered good style', even the few that are taking things too far.
Here, it's not bad but anyone who says it's the one true
way is wrong and a loudmouth.
And the same is true the other way around.
Jun 27 '08 #18

P: n/a
dhtml meinte:
Another thing that guys will say is not to use an early return.
Though I haven't heard those guys yet - why? Returning early is
considered good practice (at least in PHP) to avoid endlessly stacked
if-else-blocks.
I also
disagree with this, as I think that, as an absolute rule, it is
encumbering to the author and reader.
It's also error-prone once you get several nested if-else-blocks. And -
as you mentioned - a pain to read.

Gregor

--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jun 27 '08 #19

P: n/a
In comp.lang.javascript message <op***************@lp028.pagero.local>,
Fri, 23 May 2008 11:34:30, K Viltersten <tm**@viltersten.composted:
>Den 2008-05-23 11:17:11 skrev Tim Streater <ti**********@dante.org.uk>:
>In article <69*************@mid.individual.net>,
"K Viltersten" <tm**@viltersten.comwrote:
>>After i've taken a look at that image, i ALWAYS loose my steam
and reword my reply. I don't want to be that "tough on Usenet". :)

I feel I should point out that "lose" is spelt "lose" and not "loose".

I thought it was: loose, loosing, lost, have lost...
Well, one learnes something new every day. Thanks.
I feel I should point out that "loose" is spelt "loose" and not "lose".
KV must not believe that "loose" is not a word. But "lose" is a verb
and "loose" is usually an adjective (and "loss" is a noun).
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htmclpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.htmlnews:borland.* Guidelines
Jun 27 '08 #20

P: n/a
On Fri, 23 May 2008 at 23:02:56, in comp.lang.javascript, dhtml wrote:

<snip>
>Another thing that guys will say is not to use an early return. I also
disagree with this, as I think that, as an absolute rule, it is
encumbering to the author and reader.
<snip>

I've not seen a detailed explanation of this rule but I gather the idea
is that each function should have just one exit point. This makes it
easier to check every code path and to confirm that all code paths have
been tested (I think). However, a lot of experts agree that a few
if (nothing to do) return;
at the beginning of the function is harmless.

It's having exits buried deep inside a tangle of if's and while's that's
a problem. The usual rule : messy code is bad.

John
--
John Harris
Jun 27 '08 #21

P: n/a
On Fri, 23 May 2008 at 06:57:53, in comp.lang.javascript, Henry wrote:
>On May 23, 12:13 pm, John G Harris wrote:
<snip>
>On the other hand, if a block statement looks like a distinct
statement, which it is,

It is difficult to see how a statement that contains other statements
can ever look like a distinct statement.
<snip>

One kind of statement has the general form
if (<condition>) <statement>
That's a form of statement that contains a nested statement. As it's a
statement you can re-use it to give the form
if (<condition>) if (<condition>) <statement>
Now there's a statement nested inside a statement that itself is nested
inside a statement.

There's nothing unusual about statements containing statements. Each of
the following is a single (distinct) statement, containing none or more
statements :
{ }
{ a = 0; }
{ a = 0; b = 1; }
{ a = 0; b = 1; c = 2; }

John
--
John Harris
Jun 27 '08 #22

This discussion thread is closed

Replies have been disabled for this discussion.