RFD: How To Recognize Bad Javascript Code

On Jan 1, 1:30*pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

Jeremy J Starcher said the following on 1/1/2008 5:37 AM:

On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:

(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

And it would really help if I included

URL:http://www.mopedepot.com/jjs/HowToRe...criptCode.html

HTML Comments.
* Will cause problems when XHTML is used.

Script tag usage.
* text/javascript is an obsolete (although valid) MIME type.

But you have to use it for now if you want valid markup.

href:javascript.
* Drop #1, they all fall into the "Too stupid to know better" category.

document.write.
* Avoid it. Period.

For the most part. There are times when it comes in handy. I have
recently been working on test page for some proposed Code Worth
Recommending and I didn't want the HTML version to break in ancient
browsers that don't feature createElement. Of course, there is no
choice when using XHTML.

* Tables produced with document.write are indicative of an idiot programmer.

Yes, it is hard to imagine a case where tables should be generated
with document.write.

[snip]

* As for minification, that is an indication of bad coding practices.

I don't follow you there. The project I am currently working on
builds a library from various modules. If all are included, the file
size with comments and white-space is almost 200K (and will get bigger
in the future as more comments are added.) Running it through the YUI
"compressor" (minifier/obfuscator) reduces it to 90K. Granted, this
should only be done when the code is deployed on a production server.
One irritation is that I have to re-test everything to make sure that
minification didn't break something, but I have yet to have a problem
with this particular minifier. Of course, I run the source through
JSLint to catch typos and missing semi-colons beforehand.

Use of eval.
* The use of eval itself usually indicates bad coding, but not always.
* Whether it is a bad use of it or not depends on how it is used.
* And a beginner can't possibly know.

Is this a good use of eval?
function convertToDecimal(fraction){
return eval(fraction)

}

I don't like it.

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

function convertToDecimal(fraction){
var numerator = fraction.substring(0,fraction.lastIndexOf('/'))
var denominator = fraction.substring(fraction.lastIndexOf('/')+1)
return (numerator/denominator)

}

Testing shows that eval is a lot quicker but a newbe could never know
that it was actually a "good use" of eval.

The second version could be made more efficient. I don't know whether
it could approach the speed of using eval, but I would still prefer
it.

Browser detection.
* Spelling error with interfer versus interfere.

DOCTYPE.
* No version of IE, not just IE7, handles it that way.

JSLint.
* JSLint is a tool that attempts to make sure you code
* according to the preference and style that Douglas Crockford
* prefers.

You can filter out the stylistic concerns. Certainly I don't use the
strict whitespace option, but overall, I find it an invaluable tool.
All it takes is one mistaken keystroke to introduce an unintended
global variable (of course, Firebug spots those in its DOM view.)
Then there are unused variables, out of scope references, unfiltered
for-in loops, etc. I think it is a must for any project with more
than a few dozen lines of code.

Things you didn't cover:

The use of the "with" operator.

Always a bad idea.

Use of "new Function".

Quoting from JSLint: "Function constructor is eval." Like eval, it
occasionally has a reasonable use, but shouldn't be used as a crutch.

On Jan 1, 4:50*pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) spam.me.not.com>
wrote:

On Tue, 01 Jan 2008 13:38:43 -0500, Randy Webb wrote:

[snip]

try/catch is another of the things you didn't cover. Don't use it.

I've not used try/catch in Javascript myself, but I've done reading on it.

According to <URL:http://www.w3schools.com/js/js_try_catch.asp
try...catch statement is available in IE5+, Mozilla 1.0, and
Netscape 6. *Googling says Opera and KHTML both have it.

True enough.

I don't understand the concern ... *are there common browsers out there
that don't support it? *I've heard rumors about mobile devices, but
nothing concrete. *

Certainly there are mobile devices (and other agents) using script
engines that do not parse try-catch clauses. A good rule of thumb is
to relegate the use of try-catch to scripts that you can afford to
lose in such browsers. In other words, if you have enhancements that
will work in virtually any browser (e.g. form validation), don't lump
them in with or make them reliant upon scripts that feature try-catch
clauses (e.g. Ajax, Flash.) That way agents that ignore the scripts
with try-catch clauses can still make use of the other enhancements.

Jeremy J Starcher said the following on 1/1/2008 3:56 PM:

On Tue, 01 Jan 2008 15:32:47 -0500, Randy Webb wrote:

Jeremy J Starcher said the following on 1/1/2008 2:38 PM:
On Tue, 01 Jan 2008 13:30:25 -0500, Randy Webb wrote:
Not to name names, but had I the skill to recognize
URL: http://www.dynamicdrive.com/ > for what it was, I wouldn't have had
to unlearn so much.
Some of the first copy/paste scripts I ever used came from there. It
took a while for me to understand what was wrong with them. The first
tutorial I ever went through (web-based) was on the HTMLGoodies site
when Joe Burns was writing them. Not the best quality but at the time
the best I could find. Was enough to "Get my feet wet" and obtain the
desire to know more.

Now, I wish a good one did exist.

I know the "Code Worth Recommending Project" has taken on some of that.

No, it doesn't. That project is more of a library project than anything
else. It doesn't show how to write code, only shows the code.

They are going through some growth pains and sorting out some of the
basics. I'd be willing to donate code once they are ready for
higher-level functions.

The higher-level functions aren't exactly the best pieces of code for a
beginner to be learning from though. Good to learn coding style from but
not how to actually write the code. Hard to understand how/why to do
something if you don't understand the language itself.

As for a good tutorial: I've actually thought about writing one. Its
been over a decade since I've done any real technical writing, but I think
I could find the touch again. Like all of us, the trouble is time.

That is why you don't see any. The people that have the knowledge don't
have the time (or lack the desire) to write one.

With all the crap on the market, I don't know if my book would actually -sell-
and I'd feel obligated to c.l.j for at least -part- of the money I made on
the second edition, because the first edition will be red-lettered to
death from you guys. *grin* Not a bad thing, but I can't easily post a
credit-card number here and say 'Withdraw what you earned.'

Don't post it to Usenet, just email it to me. I won't tell anybody and
won't abuse it, I promise

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

On Jan 1, 8:37*pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) spam.me.not.com>
wrote:

On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:
(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

And it would really help if I included

URL:http://www.mopedepot.com/jjs/HowToRe...criptCode.html

Despite the comments here, the page does not seem to have been
updated. I'll stick to things others haven't mentioned:

HTML comments
The heading should be "HTML comments inside script elements".

Depreciated script tag usage
In the early days of Javascript and HTML the <script> tag took a
"language" parameter. With HTML 4, the language parameter became
depreciated.

That statement should be something like: "The language attribute was
introduced in HTML 4.0, it was immediately deprecated in favour of the
type attribute."

<URL: http://www.w3.org/TR/WD-html40-97070...html#h-9.2.1.1

Using "href:javascript"
Should note that using script for the value of the href attribute
probably indicates that a button should be used, not a link.

I don't think the term "cargo-cult programming" applies specifically
to that section, it is more a general comment about people who copy
code or patterns and could be applied to the entire article. Having
said that, I wouldn't use it at all.

Not declaring local variables (no var)
...causes large and hard-to-find complications.

While the thrust of the section is good, it gives the impression that
using var stops global variables. Better to explain that:

1. All variables should be declared
2. Global variables should be kept to a minimum
3. Declaring variables inside functions keeps them local
4. Not declaring them inside functions makes them global
*when the function is first called*.

Also, unintentional global variables *may* cause hard to find bugs,
there is no guarantee.

Not ending lines in a semi-colon ";"

This is a contentious area. Semi-colons are *required* by the
ECMAScript specification (Section 7.9), however automatic semi-colon
insertion is prescribed as a convenience. I think that they should
always be manually inserted by the programmer, others disagree. It is
at least good style in a tutorial to manually insert semi-colons to
show where they should be.

There is also argument over the use of minifiers. I think they are a
valid way to reduce code bulk, however zipping code files is probably
as effective and doesn't require 2 sets of testing.

Web pages that do not include a DOCTYPE and/or do not validate

Whenever you are tempted to use "and/or", don't. One or the other
should be used. In any case, the title doesn't make sense. A DOCTYPE
is required for valid HTML, therefore if there is no DOCTYPE, the page
is not valid HTML.

I think the point you are trying to make is something like:

Beware of invalid markup

Primary causes of invalid markup are: missing DOCTYPE declaration, use
of invalid or deprecated tags or attributes, incorrect nesting of
elements and missing required or incorrect use of element attributes
(e.g. non-unique ID attribute values). All of the above may affect
how scripts interact with the DOM and are signs of poor quality
markup. It is likely that anyone publishing poor quality HTML applies
the same level of quality control to their scripting.

Last of all, remember that it is your document. Ensure readers will
not be confused between what is required by standards, what "works"
and what doesn't and what is good practice (i.e. opinion).


--
Rob

On Jan 2, 6:22*am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

Anthony Levensalor wrote:
First, I liked your doc, and the comments on it so far have taught me a
lot.

But you despise the people that made them? *Something doesn't add up here.

Yes, it does, you're just playing cute. It's not what you say, it's
the way that you say it. You've been told that /ad nauseam/.


--
Rob

On Jan 1, 7:23*pm, RobG <rg... (AT) iinet (DOT) net.au> wrote:
[snip]

There is also argument over the use of minifiers. I think they are a
valid way to reduce code bulk, however zipping code files is probably
as effective and doesn't require 2 sets of testing.

GZIP compression should be handled by the Web server as it needs to
negotiate this with each client. Manually compressing files is a bad
idea as some clients will choke on them. Another reason to minify is
that compression (when available) will only reduce comment bulk,
whereas minification eliminates it.

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:

Anthony Levensalor wrote:

Thomas 'PointedEars' Lahn posted :

b. The term you were looking for is `script' _element_,

“‘script’ element _type_�

Elements consist of tags (start tag, close tag)

The terms you were looking for are ‘start-tag’ and ‘end-tag’. See ISO
8879, clause 7.3, or otherwise not the FAQ, part 5 (and also part 4, now
that I come to think about it .

http://www.w3.org/TR/REC-html40/intr...t.html#h-3.2.1

That’s but a for dummies introduction to SGML, found in a technical
“recommendation� that itself has a hard time to get all this SGML arcane
right.

Funny thing is, I looked that page up and down buddy, and I didn't see
anything about a script _element_ anywhere. Maybe your underscore is broken.

Maybe you are an idiot. (See, *now* I said it.)

And he didn’t even say that there is no notion of a ‘`script'’
element type *anywhere* in HTML 4.

--
DELIM
GENERAL SGMLREF
STAGO "`"
TAGC "'"

Eric B. Bednarz wrote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:
Anthony Levensalor wrote:
Thomas 'PointedEars' Lahn posted :
b. The term you were looking for is `script' _element_,

“‘script’ element _type_”

`script' is definitely an element type, but "Deprecated `script' element
type usage" would indicate that the element type itself is deprecated, which
it is not.

Elements consist of tags (start tag, close tag)

The terms you were looking for are ‘start-tag’ and ‘end-tag’. See ISO
8879, clause 7.3, or otherwise not the FAQ, part 5 (and also part 4, now
that I come to think about it .

There is no requirement for a hyphen in compound words in English.

You are merely splitting hairs while I was pointing out the use of wrong
technical terms -- a slight, but important difference.


PointedEars

On Tue, 01 Jan 2008 16:23:28 -0800, RobG wrote:

On Jan 1, 8:37*pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) spam.me.not.com
wrote:
On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:
(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid
the same hair pulling that I went through.

And it would really help if I included

URL:http://www.mopedepot.com/jjs/HowToRe...criptCode.html

Despite the comments here, the page does not seem to have been updated.
I'll stick to things others haven't mentioned:

Give me a break. *grin*
There have only been about nine hours since I woke up and read the first
comments and now. That time has been used in this discussion and
rewriting the page. I'll really try to get the updated version up tonight
though.

HTML comments
The heading should be "HTML comments inside script elements".

Depreciated script tag usage
In the early days of Javascript and HTML the <script> tag took a
"language" parameter. With HTML 4, the language parameter became
depreciated.

That statement should be something like: "The language attribute was
introduced in HTML 4.0, it was immediately deprecated in favour of the
type attribute."

OH... I like that phrasing.

URL:
http://www.w3.org/TR/WD-html40-97070...html#h-9.2.1.1


Using "href:javascript"
Should note that using script for the value of the href attribute
probably indicates that a button should be used, not a link.

I don't think the term "cargo-cult programming" applies specifically to
that section, it is more a general comment about people who copy code or
patterns and could be applied to the entire article. Having said that,
I wouldn't use it at all.

Not declaring local variables (no var) ...causes large and hard-to-find
complications.

While the thrust of the section is good, it gives the impression that
using var stops global variables. Better to explain that:

1. All variables should be declared
2. Global variables should be kept to a minimum 3. Declaring variables
inside functions keeps them local 4. Not declaring them inside
functions makes them global
*when the function is first called*.

Also, unintentional global variables *may* cause hard to find bugs,
there is no guarantee.

That is one of the sections I'm re-writing, trying to make it much more
clear yet ... able to grasp the concept. Some of that is more detail than
I need for this purpose.

Not ending lines in a semi-colon ";"

Yea.. that whole section is going.

Web pages that do not include a DOCTYPE and/or do not validate

Whenever you are tempted to use "and/or", don't. One or the other
should be used. In any case, the title doesn't make sense. A DOCTYPE
is required for valid HTML, therefore if there is no DOCTYPE, the page
is not valid HTML.


I think the point you are trying to make is something like:

Beware of invalid markup

Primary causes of invalid markup are: missing DOCTYPE declaration, use
of invalid or deprecated tags or attributes, incorrect nesting of
elements and missing required or incorrect use of element attributes
(e.g. non-unique ID attribute values). All of the above may affect how
scripts interact with the DOM and are signs of poor quality markup. It
is likely that anyone publishing poor quality HTML applies the same
level of quality control to their scripting.

*nod* I'll go for that. Nicely worded.

Last of all, remember that it is your document. Ensure readers will not
be confused between what is required by standards, what "works" and what
doesn't and what is good practice (i.e. opinion).

Part of the reason I asked for comments. Sometimes I'm too close to it to
read it as an outsider.

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

From all evyll and myschief, from synne, from the craftes and assaultes
of the devill, from thy wrath, and from everlastyng damnacion.

Good lorde deliver us.

From blindnes of hearte, from pryde, vaynglory, and hypocrisy, from
envy, harred and malice, and all uncharytablenes:

Good lorde deliver us.

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

Good lorde deliver us.

From lightnyng and tempast, from plage, pestilence and famyne, from
battayle and murder, & from sodaine death:

Good lorde deliver us.

From all sedycion and privey conspiracie, from the tyranny of the
bisshop of Rome and all his detestable enormyties, from all false
doctrine and heresye, from hardnes of hearte, and conmtempte of thy
worde and commaundemente:

Good lorde deliver us.

By the mystery of thy holy incarnacion, by thy holye nativyte and
cirumcysyon, by the baptyisme, fastynge and temptacyon:

Good lorde deliver us.

By thyne agony and bluddy sweate, by thy crosse and passion, by thy
precious death and buryal, by thy glorious resurrectyon and ascension,
by the commyng of the holy Ghost:

Good lorde delyver us.

In al time of our tribulacion, in al tyme of our wealth, in the hour of
death, in the day of judgment:

Good lorde deliver us.

--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)