How optimized ar eif-statements in JS

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

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.

On May 23, 6:57 am, Henry <rcornf... (AT) raindrop (DOT) co.uk> wrote:

On May 23, 12:13 pm, John G Harris wrote:

Henry wrote:

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?

It makes the code a little longer with some clutter.

function xxx(el) {
if(!el) return;
alert(el.tagName);
}

function xxx(el) {
if(!el) {
return;
}
alert(el.tagName);
}

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. if(!el) return means "if the el
param is missing, exit." It says this right at the top, so the reader
doesn't have to read through the whole method. It keeps the
indentation level down, too.

function xxx(el) {
if(el) {
alert(el.tagName);
// more stuff with el.
}
}

The "no early returns" rule is the that annoys me the most, and its
usually the rule I will take up debate regarding.

Things like always using curly braces (blocks, not statements), I can
just do it and shut up. Same with curly brace on the next line:
if(b)
{

}

Although I don't usually write that way. If I have to, I can.

Just my .02 on code style.

What code formatters do guys here use?

In comp.lang.javascript message <op.ublovsf0i74t80 (AT) lp028 (DOT) pagero.local>,
Fri, 23 May 2008 11:34:30, K Viltersten <tmp1 (AT) viltersten (DOT) com> posted:

Den 2008-05-23 11:17:11 skrev Tim Streater <tim.streater (AT) dante (DOT) org.uk>:

In article <69mvq6F33o7alU1 (AT) mid (DOT) individual.net>,
"K Viltersten" <tmp1 (AT) viltersten (DOT) com> wrote:

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.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines

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

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