Conditional Operator and style/correctness

[Zack]

Hi,

Let's say you have this function named validate. validate looks like
this:

function validate() {
return ($F("Email") != '' ? ($("Name").valu e = $F("Email")) :
false);
}

(Using prototype.js. For those not familiar $() is like getElementById
and $F is like getElementById( ).value for form elements) There's a lot
happening on this 1 line so let's break it down.

If the value of element "Email" is not empty string, return the result
of setting value of element "Name" = the value of element "Email",
otherwise return false.

This works exactly as I want it too, but is it OK? By OK I mean good
javascript style? There's something fishy smelling to me about doing
any sort of assignment in the expression part of the conditional. It's
kind of cool that it all works because ($("Name").valu e =
$F("Email")) returns a truthy value when the value of "Email" is not
falsy

If anyone can give me some expert input that would be wonderful. Smack
this idea out of my head, or caution me it may lead to other
unintended side effects, or tell me yes, this is awesome and I'm a
ninja! I've checked around this group and Douglas Crockford's site,
but haven't found anything definitive.

The safer, more standard way of writing this, to take the assignment
out of the expression would be

function validate() {
$("Name").val ue = $F("Email");
return ( ($F("Email") != '') ? true : false);
}

But it's just not as cool looking. What does everyone think?

[Tom de Neef]

Re: Conditional Operator and style/correctness

"Zack" <zhalbrecht@gma il.comwrote

Hi,
>
Let's say you have this function named validate. validate looks like
this:
>
function validate1() {
return ($F("Email") != '' ? ($("Name").valu e = $F("Email")) :
false);
}
>

The result of the assignment $("Name").val ue = $F("Email") is $F("Email").
Hence, the function returns either $F("Email") or false.
That is not the same as

function validate2() {
$("Name").val ue = $F("Email");
return ( ($F("Email") != '') ? true : false);
}

where the function returns either true or false.
That may not be a problem, because the return value will be converted to a
boolean if you use it in a conditional expression. But if you don't mind
about that anyway, then you may as well use:

function validate3() {
$("Name").val ue = $F("Email");
return $F("Email")
}

which can be shortened to
function validate4() {
return $("Name").val ue = $F("Email") }

But if you want to understand your code a year from now, it would be best
not to make it too dense. validate3 would be my preference. But that is just
a matter of opinion and I am not an expert.
Tom

[Zack]

Re: Conditional Operator and style/correctness

On May 1, 3:21 pm, "Tom de Neef" <tden...@qolor. nlwrote:

"Zack" <zhalbre...@gma il.comwrote
>

Hi,

>

Let's say you have this function named validate. validate looks like
this:

>

function validate1() {
return ($F("Email") != '' ? ($("Name").valu e = $F("Email")) :
false);
}

>
The result of the assignment $("Name").val ue = $F("Email") is $F("Email").
Hence, the function returns either $F("Email") or false.
That is not the same as
>
function validate2() {
$("Name").val ue = $F("Email");
return ( ($F("Email") != '') ? true : false);
>
}
>
where the function returns either true or false.
That may not be a problem, because the return value will be converted to a
boolean if you use it in a conditional expression. But if you don't mind
about that anyway, then you may as well use:
>
function validate3() {
$("Name").val ue = $F("Email");
return $F("Email")
>
}
>
which can be shortened to
function validate4() {
return $("Name").val ue = $F("Email") }
>
But if you want to understand your code a year from now, it would be best
not to make it too dense. validate3 would be my preference. But that is just
a matter of opinion and I am not an expert.
Tom

Thanks for the reply Tom. I guess I'm looking for more of an academic
discussion of why you should or should not do something like my
original.

A friend just pointed out really a major difference between my first
and second versions is that in validate2, the assignment always
happens. In validate1, it's um, conditional :-) So...yeah. Not sure if
this is important here, but it seems like it might be. validate1
always causes the side effect of assignment, validate2 only causes
that side effect if warranted by the condition.

[Dr J R Stockton]

Re: Conditional Operator and style/correctness

In comp.lang.javas cript message <cae741d7-de81-4549-afea-c39da270ef49@34
g2000hsh.google groups.com>, Thu, 1 May 2008 12:03:04, Zack
<zhalbrecht@gma il.composted:

>
>Let's say you have this function named validate. validate looks like
>this:
>
>function validate() {
return ($F("Email") != '' ? ($("Name").valu e = $F("Email")) :
>false);
>}
>
>(Using prototype.js. For those not familiar $() is like getElementById
>and $F is like getElementById( ).value for form elements) There's a lot
>happening on this 1 line so let's break it down.
>
>If the value of element "Email" is not empty string, return the result
>of setting value of element "Name" = the value of element "Email",
>otherwise return false.

IMHO, the type of the return value of a function should not generally
vary. While the context in which the result is used will normally
indicate an appropriate interpretation, it might not always do so.

The code can evaluate $F("Email") twice, which seems inefficient.

I'd reverse the test, to dispose of the simple case first.

Contemplate these :


function validate01() { var X
X = $F("Email")
return X && ( $("Name").val ue = X ) } returns string

function validate01() { var X
X = $F("Email")
return !!( X && ( $("Name").val ue = X ) ) } returns Boolean

function validate03() { var X
X = $F("Email")
if (X) $("Name").val ue = X
return !!X } // returns Boolean

function validate04() { var X
X = $F("Email")
if (!X) return false
$("Name").val ue = X
return true } // returns Boolean

UNTESTED.

BTW : there is so much spam from @gmail in some groups that there is a
temptation to kill all @gmail articles; consider using a respectable
address.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

--
(c) John Stockton, nr London UK. ?@merlyn.demon. co.uk IE7 FF2 Op9 Sf3
news:comp.lang. javascript FAQ <URL:http://www.jibbering.c om/faq/index.html>.
<URL:http://www.merlyn.demo n.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Richard Cornford]

Re: Conditional Operator and style/correctness

Zack wrote:

Hi,
>
Let's say you have this function named validate. validate looks
like this:
>
function validate() {
return ($F("Email") != '' ? ($("Name").valu e = $F("Email")) :
false);
}
>
(Using prototype.js. For those not familiar $() is like
getElementById and $F is like getElementById( ).value for form
elements) There's a lot happening on this 1 line so let's break
it down.
>
If the value of element "Email" is not empty string, return the
result of setting value of element "Name" = the value of
element "Email", otherwise return false.
>
This works exactly as I want it too, but is it OK? By OK I mean
good javascript style? There's something fishy smelling to me
about doing any sort of assignment in the expression part of
the conditional.

There is an often expressed style opinion that code that produces side
effects should not appear in the expressions of a conditional operation;
that under those circumstances an - if/else - block would be more
appropriate, and make the side effect easier to observe. The assignment
to the 'Name' field probably qualifies as a side effect in this case.
One branch of responses to this thread seems to suggest that the
side-effect in the conditional expression was not as apparent as it
should be.

However, in any programming language it would be considered bad style to
be disregarding a language usage convention that appears in the
language's specification, and as Prototype.js disregards ECMA 262 (all
versions)'s injunction against using the $ symbol as the first character
in any Identifier that is not machine generated if you are using
Prototype.js it is already too late to be worrying about 'good style'.

<snip>

But it's just not as cool looking. ...

Programming is an activity where producing 'cool looking code' is never
going to be a reason for doing anything. If 'cool looking' is a side
effect of doing the right thing then so be it, otherwise it is a mistake
to be doing anything but the right thing.

Richard.