RFD: How To Recognize Bad Javascript Code

In article <qqOdnWNTP6hgb-HaRVn_vwA (AT) giganews (DOT) com>,
Randy Webb <HikksNotAtHome (AT) aol (DOT) com> wrote:

Evertjan. said the following on 3/1/2008 7:33 AM:

snip

This is certainly NOT off topic in this NG.

You don't think that the meaning of words, and the history of the
meanings, is off-topic here? Sounds more like it would be better in a
group dedicated to the meanings and history of words.

I didn't see the posts that led to the above, but if the use of the word
'deprecate' is appropriate in this NG, as would seem very likely, then a
brief discussion which might avoid the incorrect use of a similar
sounding or looking word is relevant here.

John W. Kennedy wrote:

Thomas 'PointedEars' Lahn wrote:
a. The word you were looking for is _deprecated_, not "depreciated".

Actually, "depreciated" is the correct word.

For all intents and purposes, "depreciated" means a different thing as
"deprecated". The word "deprecated" was suggested by choice, as that is the
word for "not recommended" and "next to obsolete" used in Web standards.
And that is a meaning that not only applies to the given example of bad
style but is also widely understood, no matter the actual etymology. But
even the common dictionaries contradict you. However, you of all people
should know that a language is developing as the society that created it is
developing. To insist on the use or not-use of a word because of its
etymology is denying that.

Some moron about 75 years ago decided that "deprecated" sounded more kewl,

I seriously doubt that because AFAIK the word "cool" did not gain the
meaning of "fashionable/hip" before the 1950s (with Cool Jazz), and the
spelling "kewl" did not come up before the 1990s.

Besides, I really don't care about this person nor about your appreciation
(or rather the lack thereof) of their doing. We are discussing programming
here.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

On Thu, 03 Jan 2008 09:21:57 -0500, Randy Webb wrote:

Jeremy J Starcher said the following on 1/2/2008 11:21 PM:

A search for navigator is a better search to use. If a different
variable name is used then you miss it. If you search for navigator you
will find where it is used or defined.

Should be used in combination, since I GoogleCode provided these "gems"
in on the search of "lang:javascript isie"

var IsIE = (document.all)
var isIE=(window.ActiveXObject)
var isIE = document.createElementNS==null;

/* DOUBLE YECK */
var isIE = navigator.appName == 'Microsoft Internet Explorer' ? 1 : 0;

While I may end up with code that is less efficient than "the best
possible code," I believe that these simple things narrow down my
choices. As a Javascript novice, I would have found a 'Best Practices'
article too much -- well, at least the "Best Practices" I'd end up
writing.

Have you read Matt's?

Of course.

Since you've stated multiple time you think a 'Best Practices' document
is the way to go, I had assumed you wanted something more comprehensive.

(Good grief, can you /imagine/ the discussion about what "best
practices" would be like? I doubt we could even agree on a brace
style, though K&R did show the only way. *weg*)

How they do things in C is irrelevant to how you do them in JS

As I've been told more than once here lately. JS *did* borrow braces
from C, so we should at least borrow how to USE them too. *evil grin*

Best Practices document discussion? It has already happened here when
Matt wrote his.

URL:
http://groups.google.com/group/comp....browse_thread/
thread/c532483403801387/738bf21b7896d015?lnk=gst&q=matt+kruse+best

+practices#>

Now that I've not read ... yet. Will most likely be lunchtime
entertainment.

And no, you won't get three people in this group to agree on much of
anything unless it is a condemnation of anything a particular poster has
to say about Javascript. The last time the name was mentioned it got
changed out with ** to mask the name.

Ah.. usenet. Somethings never change.
We couldn't agree on a lot in Unix shell scripting either.

In comp.lang.javascript message <cLWdnSPqp_3QZ-ba4p2dnAA (AT) giganews (DOT) com>,
Wed, 2 Jan 2008 15:56:23, Randy Webb <HikksNotAtHome (AT) aol (DOT) com> posted:

Dr J R Stockton said the following on 1/2/2008 7:14 AM:
In comp.lang.javascript message <4IidnY9-v9gXG-faRVn_vwA (AT) giganews (DOT) com>,
Tue, 1 Jan 2008 13:30:25, Randy Webb <HikksNotAtHome (AT) aol (DOT) com> posted:
Is this a good use of eval?
function convertToDecimal(fraction){
return eval(fraction)
}

Where fraction is a fraction that you need converted to decimal? It can
be written like this:

If that string is supplied from outside, then the case is already
covered as "not known at run time". Return.

Define "supplied from outside".

See FAQ 4.40.

The string is supplied as the value of a select element.

If that's the displayed value, it is essentially outside.
If that value is to be sent to a server, it is headed for outside.
Otherwise, a string is not a good representation; just a simple-minded
one. I should of course have written "from/to outside".

Otherwise, no : it is not a good use of eval.
Evidently the argument 'fraction' is intended to be a string. But a
string is not a good way of representing a fraction internally.

It is when it is the value of a select element.

That is designed for external use, and does not make it a good internal
representation.

Analogy : numbers are always I/O as strings, but internally represented
as Doubles. Having internal Doubles was a language design choice. The
language would have been much better for idiot coders, but slower to run
and much worse for implementors, if numbers were held internally as
full-accuracy decimal strings.

A rational fraction should be represented as {Num:n; Den:d} or similar, or
as a case of {Typ:F; Num:n; Den:d}, or as a simple case of a structure
designed to hold general expressions (a tree for arithmetic notation; an
array or list for RPN).

Or a simple string. KISS.

Things should be as simple as is efficient, but no simpler. It's better
to be right than to be simple.

Analogy : the initial choice of getYear() giving a value in 0..99.
Given that the internal workings must handle more than one century, it
would have been no harder for the implementors to have given the full
year. Coders wanting 0..99 would have merely needed to use %100 (and
would have been reminded of Y2k thereby); coders wanting the proper year
would have been saved much inconvenience.

That's been compounded by an idiotic choice, for getYear outside years
1900-1999, of returning the full year (ISO16262 calls for, and Opera &
Firefox give, Year-1900 always).

It is only bad data design that makes the use of 'eval' seem appropriate
for that purpose.

It isn't bad data design at all. When you need a number in two forms -
both decimal and fraction - and you choose which one to use where, the
best way is to keep the fraction as a string and convert it to decimal
when needed.

Wrong, unless the amount of decimal is very small. A rational fraction
is an ordered pair of numbers (as a complex number is), and should be
held as such.

But remember : my aim is not to make you understand, but to give
everyone else no reason to be deceived.

--
(c) John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??.Stockton (AT) physics (DOT) org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

Jeremy J Starcher said the following on 1/3/2008 11:30 AM:

On Thu, 03 Jan 2008 09:21:57 -0500, Randy Webb wrote:

Jeremy J Starcher said the following on 1/2/2008 11:21 PM:

A search for navigator is a better search to use. If a different
variable name is used then you miss it. If you search for navigator you
will find where it is used or defined.

Should be used in combination, since I GoogleCode provided these "gems"
in on the search of "lang:javascript isie"

var IsIE = (document.all)
var isIE=(window.ActiveXObject)
var isIE = document.createElementNS==null;

All three of which fall into the category of browser inference. They
make the assumptiont hat because the browser does, or does not, support
a certain feature then it must be that browser. Another of the "Bad
Practices" you see on the web.

var notIE = !document.all;

That is why I think a Best Practices type document where it explains
that you should use feature detection instead of feature inference is
better than trying to show all the backwards ways you can do Bad Coding.

/* DOUBLE YECK */
var isIE = navigator.appName == 'Microsoft Internet Explorer' ? 1 : 0;
While I may end up with code that is less efficient than "the best
possible code," I believe that these simple things narrow down my
choices. As a Javascript novice, I would have found a 'Best Practices'
article too much -- well, at least the "Best Practices" I'd end up
writing.
Have you read Matt's?

Of course.

Since you've stated multiple time you think a 'Best Practices' document
is the way to go, I had assumed you wanted something more comprehensive.

I think a good, solid tutorial is better than either one. Rather than a
"Do this" or "Don't do this", show the best way to do it. Then, it can
grow, separate into different areas, and keep growing.

(Good grief, can you /imagine/ the discussion about what "best
practices" would be like? I doubt we could even agree on a brace
style, though K&R did show the only way. *weg*)
How they do things in C is irrelevant to how you do them in JS

As I've been told more than once here lately. JS *did* borrow braces
from C, so we should at least borrow how to USE them too. *evil grin*

I won't argue that it "borrowed" anything from anywhere. I will argue
with the assertion that "It is done this way in /insert name/ so it
should be done that way in JS".

Best Practices document discussion? It has already happened here when
Matt wrote his.

URL:
http://groups.google.com/group/comp....browse_thread/
thread/c532483403801387/738bf21b7896d015?lnk=gst&q=matt+kruse+best
+practices#

Now that I've not read ... yet. Will most likely be lunchtime
entertainment.

For a week or so of lunchtimes

And no, you won't get three people in this group to agree on much of
anything unless it is a condemnation of anything a particular poster has
to say about Javascript. The last time the name was mentioned it got
changed out with ** to mask the name.

Ah.. usenet. Somethings never change.
We couldn't agree on a lot in Unix shell scripting either.

It isn't just Usenet, it is the web in general. If you want to find a
document that can back up an assertion (any assertion), you can pretty
much find it on the web. It is the open-ness that both bring that causes
it. And it isn't always a bad thing either. Sometimes, seeing a
different way of doing something helps even in the way you do it yourself.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Response to Tim Streater <tim.streater (AT) dante (DOT) org.uk>:

In article <qqOdnWNTP6hgb-HaRVn_vwA (AT) giganews (DOT) com>,
Randy Webb <HikksNotAtHome (AT) aol (DOT) com> wrote:

Evertjan. said the following on 3/1/2008 7:33 AM:

snip

This is certainly NOT off topic in this NG.

You don't think that the meaning of words, and the history of the
meanings, is off-topic here? Sounds more like it would be better
in a group dedicated to the meanings and history of words.

I didn't see the posts that led to the above, but if the use of
the word 'deprecate' is appropriate in this NG, as would seem very
likely, then a brief discussion which might avoid the incorrect
use of a similar sounding or looking word is relevant here.

That sounds like a clever attempt at semantics and the production of
off-topic replies.

If for example I discuss that a woman I once knew got turned on by
talking about code, programming, and hence JavaScript -- would sexual
geek fetishes be on-topic here?

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

On Tue, 1 Jan 2008 at 20:29:54, in comp.lang.javascript, John W. Kennedy
wrote:

Thomas 'PointedEars' Lahn wrote:
a. The word you were looking for is _deprecated_, not "depreciated".

Actually, "depreciated" is the correct word. Some moron about 75 years
ago decided that "deprecated" sounded more kewl, and got the two words
hopelessly confused. Properly, to deprecate something is to pray to be
protected from it, ee.g.:
snip

And awful used to mean awe-inspiring.

More to the point, 'deprecated' is the word to be used in ISO standards
where it has a specific meaning regardless of dictionaries, as in

"These are deprecated features, where deprecated is defined as:
Normative for the current edition of the Standard, but not guaranteed to
be part of the Standard in future revisions."
[copied from the C++ standard]

(Normative means defined by this standard).

From all fornycacion and all deadly synne, and from all the deceiptes
of the worlde, the fleshe, and the devill:

Good lorde deliver us.
snip

.... but not yet.


John
--
John Harris

In comp.lang.javascript message <8d803126-36b2-4752-8353-499dfd387e01@e6
g2000prf.googlegroups.com>, Wed, 2 Jan 2008 16:58:43, David Mark
<dmark.cinsoft (AT) gmail (DOT) com> posted:

On Jan 2, 4:00*pm, Dr J R Stockton <j... (AT) merlyn (DOT) demon.co.uk> wrote:
In comp.lang.javascript message <8331b1ee-5f11-4391-bdc6-05d427912e5f@e2
6g2000hsh.googlegroups.com>, Tue, 1 Jan 2008 16:35:16, David Mark
dmark.cins... (AT) gmail (DOT) com> posted:

*Another reason to minify is
that compression (when available) will only reduce comment bulk,
whereas minification eliminates it.

ISTM wrong always to use something that eliminates all comment, even on
a fully-commercial page not intended to be read. *Comment explaining the
code should be removed; but comment identifying the source and date can
be worth retaining.

Absolutely. I typically add copyright and version information at the
top after minification.

But then you have no guarantee of consistent correctness in matching the
minified version with the correct original, unless the process is
adequately automated. Anything a human can do, he/she can occasionally
do wrong. At least an automated process can be consistently or
repeatably wrong. - like this spelling-checker, which rejects
"repeatably" - repeatably.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

In comp.lang.javascript message <cff62c4b-e5fc-4882-90f4-ab0242cc186a@i3
g2000hsf.googlegroups.com>, Wed, 2 Jan 2008 20:53:30, David Mark
<dmark.cinsoft (AT) gmail (DOT) com> posted:

On Jan 2, 11:21*pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) com> wrote:
On Wed, 02 Jan 2008 12:18:12 -0500, Randy Webb wrote:
If it is going into a "Bad Code" document then shouldn't you endeavor to
show the best possible way to do it? And that is why I said that I
thought that a Best Practices document is a better way to go than a Bad
Practices document. The Best document can have an end to it, the Bad
document can never ever cover all the bad code you might (and probably
will) encounter on the web.

Its not my goal to show every single thing that can make for bad code,
but I do believe that there are a /small/ and /limited/ number of things
that truly awful code will have in common.

When I am trying to find a code snippet that will do something I need,
the *first* thing I do is search for the variable "isIE". * If not found,

Similarly, any hits for "userAgent" indicate that the code can be
dismissed out of hand.

Not necessarily. What's wrong with a page, originated by programmer A
but nowadays maintained by good programmer B, that contains

// Code replaced, B, yyyy-mm-dd : was
/* ... userAgent ... */
<feature-testing code>


For a really bad sign, consider current code that, with D = new Date(),
Y2k-corrects getYear() then uses that in conjunction with getUTCMonth()
... getUTCSeconds() !

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<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

-Lost said:

If for example I discuss that a woman I once knew got turned on by
talking about code, programming, and hence JavaScript -- would sexual
geek fetishes be on-topic here?

Well, I mean, are they ever NOT on topic?

~A!

--
anthony at my pet programmer dot com