[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

"undefined"?

ram

1/7/2016 1:49:00 AM

I remember the advice: "Don't assign »undefined«
to something, only use it for testing (as in
»... === undefined«)."

But I forgot the reason.

Could it be that we do not want to write

..property = undefined

so that the /existing/ property with the value
»undefined« is not mistaken for a property that
does not exist? And we do not want to write

function() { ... return undefined; }

so that this function that returns something
which happens to be the value »undefined« is
not mistaken for a function that does not
return anything at all?

Or are there other reasons?

Which of the following three fragments should
be preferred, and why?

square_root(x) { if( x < 0 )return NaN; ... }
square_root(x) { if( x < 0 )return null; ... }
square_root(x) { if( x < 0 )return undefined; ... }

(actually, the word »undefined« best expresses the
mathematical way of wording, which says that the
square root of -1 is not defined [in the reals].)


1 Answer

Thomas 'PointedEars' Lahn

1/7/2016 3:21:00 AM

0

Stefan Ram wrote:

> I remember the advice: "Don't assign »undefined«
> to something, only use it for testing (as in
> »... === undefined«)."
>
> But I forgot the reason.
>
> Could it be that we do not want to write
>
> .property = undefined
>
> so that the /existing/ property with the value
> »undefined« is not mistaken for a property that
> does not exist? And we do not want to write

That can be one reason. Another reason is that â??undefinedâ? (different to
â??nullâ?, â??trueâ? and â??falseâ?) is actually a property of the global object
(IMHO a mistake in language design) that had not been read-only in the past.
However, the latter reason also casts into doubt the recommendation to
compare strictly against â??undefinedâ?.

<http://www.ecma-international.org/ecma-262/6.0/index.html#sec-und...

So when backwards compatibility is important (in my work it always is), I
recommend to compare â??typeof â?¦ == "undefined"â? instead of â??â?¦ === undefinedâ?.
JSHint begs to differ by default because of â??==â?, but can be convinced with

{
"eqeqeq": false
}

in the projectâ??s .jshintrc (you can, of course, also skip this and use â??===â?
at slightly reduced backwards compatibility; I am presently not certain if
the implementation versions that had a writable â??undefinedâ? property
directly correspond with those that did not yet support the â??===â? operator).

<http://jshint.com/docs/op...

[If you never tried Atom with preinstalled â??language-javascriptâ? and post-
installed â??linter-jshintâ? package, I strongly recommend that you do that
soon. After 10 years of preferring Eclipse, I am in the process of
switching from Eclipse to Atom, and that *fast* validation-as-you-type is
one important reason for it.]

> function() { ... return undefined; }
>
> so that this function that returns something
> which happens to be the value »undefined« is
> not mistaken for a function that does not
> return anything at all?

A function always returns a value. If it does not return a value
explicitly, it returns the initial value of the â??undefinedâ? property.
Therefore,

return undefined;

is better written

return;

not least for the reasons given above.

> Which of the following three fragments should
> be preferred, and why?
>
> square_root(x) { if( x < 0 )return NaN; ... }

Of the posted variants, this one is to be preferred because the function
would return a value of type Number if it succeeded. The number of
different types that a function returns should be minimized.

However, since the function would have been called with an unsupported
argument, it makes more sense to throw an exception or do not do any preior
checks if an exception would be thrown by the operation anyway *and* if from
the latter exception message it would be obvious to the caller what they did
wrong. One must resist the temptation to make it too comfortable for the
caller because that will actually cause greater trouble for all later, like
excessive overloading to make it â??easyâ? to use a function.

> square_root(x) { if( x < 0 )return null; ... }

This variant should be avoided because â??nullâ? indicates that otherwise an
object reference would be returned, which it actually would not with a
square root function.

> square_root(x) { if( x < 0 )return undefined; ... }

Also to be avoided in this case, but also see above.

> (actually, the word »undefined« best expresses the
> mathematical way of wording, which says that the
> square root of -1 is not defined [in the reals].)

But: 1/0 === Infinity

(It is unwise to ask for opinions and at the same make it clear that one has
already formed an opinion.)

Goodnight ;-)

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.