How optimized ar eif-statements in JS

[K Viltersten]

In my experience (not JS-related, of course but still from

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

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.

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?

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.

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.

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.

 

[K Viltersten]

I believe it's far finer and harder to always be polite and mature

So much for that.

Yes. Agreed.

It is about reading toughly, not replying.


This is not funny (or relevant).

I disagree but i'm sorry if it offended you. My mistake.

Score adjusted

What score?

 

[Henry]

Henry wrote:

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.

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

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.

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.

 

[dhtml]

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?

 

[Gregor Kofler]

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

 

[Dr J R Stockton]

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

 

[John G Harris]

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

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 G Harris]

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


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