RFD: How To Recognize Bad Javascript Code

In article <477ae913$0$13902$607ed4bc (AT) cv (DOT) net>, "John W. Kennedy" <jwkenne (AT) attglobal (DOT) net> 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.:

Wrong on all counts. You need to find yourself a better dictionary.
"Deprecate" means to belittle; "depreciate" means to reduce the value of. The
Latin *root* of "deprecate" means to pray to be protected from, but that is
not its English meaning, properly or otherwise.

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Doug Miller wrote:

In article <477ae913$0$13902$607ed4bc (AT) cv (DOT) net>, "John W. Kennedy" <jwkenne (AT) attglobal (DOT) net> 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.:

Wrong on all counts. You need to find yourself a better dictionary.
"Deprecate" means to belittle; "depreciate" means to reduce the value of. The
Latin *root* of "deprecate" means to pray to be protected from, but that is
not its English meaning, properly or otherwise.

That /is/ its English meaning -- its only English meaning until the
early 20th century when, as I said, some moron got the two words mixed
up. The fact that modern dictionaries perforce have to acknowledge the
mistake doesn't change that.


--
John W. Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

David Mark said the following on 1/1/2008 5:10 PM:

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.

I do?

<script type="">
alert('Just checking')
</script>

The W3 validator validates it just fine. And all the PC based browsers I
tested it on happily gave me the alert.

So much for "valid HTML", eh?

The W3 validator doesn't care if it there is an invalid, obsolete, valid
or anything else in it, as long as type="..." is present.

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.

For a newbe, it is best to avoid document.write at all. It falls into
the eval, new Function, etc.. category where you should avoid it until
you understand it.

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

When I refer to minification, it is the removal of CR/LF that I have the
problem with. Removing whitespace and comments is a good thing in
production code, just not new lines. Even you say you have to re-test
everything after doing it. If all you do is remove whitespace and
comments then there is no need to re-test. Makes the test time double.
Not a very good thing.

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.

It is the most efficient way to do it. And, it is one of the intended
uses of eval.

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.

I typed that function off the top of my head to show the differences.
You could make it more efficient:

function convertToDecimal(fraction){
myNumber = fraction.split('/')
return (myNumber[0]/myNumber[1])
}

The first time I ever ran into that situation, I posted about it here.
That was in 2003.
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/88a3a41b107b98d8/452824d170405e83?lnk=gst&q=fraction+decimal+eval+s elect&rnum=1#452824d170405e83>

The test page in that thread is still up, although this URL:
<URL: http://members.aol.com/_ht_a/hikksnotathome/evalTest/index.html>
is a better URL to use because it kills the hometown crap AOL injects.

Richard posted test code that actually shows that the non-eval version
is slightly faster in non-IE browsers.

JFTR though, I use the non-eval version (even to this day) and that is
even with a different company. Even though it is a legitimate use of eval.

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.

I wasn't referring to the style aspect of how you indent code. Every
programmer has a "style" they use/prefer. The one that JSLint compares
against is Douglas' preferred "style" of coding. The use of statement
ending semicolons being the biggest one.

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.

Don't get me wrong, I use JSLint. It is just that I don't agree with all
of the things it will tell you about code. When I do use it, I do the
things that JSLint wants me to do to kill the error messages, then I
have to undo it to get it back to what I wanted. Mostly with concerns
for semicolons though.

--
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, 10:16*pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

David Mark said the following on 1/1/2008 5:10 PM:





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.

I do?

script type=""
alert('Just checking')
/script

The W3 validator validates it just fine. And all the PC based browsers I
tested it on happily gave me the alert.

So much for "valid HTML", eh?

That is valid markup (but an odd choice) and as there is type
indicated, browsers use the default of JavaScript. This is valid too:

<script type="application/javascript">
...
</script>

But is not recommended as it could confuse older browsers. So you are
left with two choices ("text/javascript" or ""), only one of which is
clear.

David Mark said the following on 1/1/2008 10:34 PM:

On Jan 1, 10:16 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
David Mark said the following on 1/1/2008 5:10 PM:
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.
I do?

script type=""
alert('Just checking')
/script

The W3 validator validates it just fine. And all the PC based browsers I
tested it on happily gave me the alert.

So much for "valid HTML", eh?

That is valid markup (but an odd choice) and as there is type
indicated, browsers use the default of JavaScript. This is valid too:

script type="application/javascript"
...
/script

But is not recommended as it could confuse older browsers. So you are
left with two choices ("text/javascript" or ""), only one of which is
clear.

As for "validity", this is valid HTML:

<script type="HikkScript">

The difference is that browsers won't execute the script block.

I just find it ironically amusing is all.

--
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, 10:53*pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

David Mark said the following on 1/1/2008 10:34 PM:





On Jan 1, 10:16 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
David Mark said the following on 1/1/2008 5:10 PM:
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 avoidthe
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.
I do?

script type=""
alert('Just checking')
/script

The W3 validator validates it just fine. And all the PC based browsers I
tested it on happily gave me the alert.

So much for "valid HTML", eh?

That is valid markup (but an odd choice) and as there is type
indicated, browsers use the default of JavaScript. *This is valid too:

script type="application/javascript"
...
/script

But is not recommended as it could confuse older browsers. *So you are
left with two choices ("text/javascript" or ""), only one of which is
clear.

As for "validity", this is valid HTML:

script type="HikkScript"

Right. The validator only cares about the structure of the markup.

David Mark posted :

[snip]

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.

This is an excellent tip, thanks! I've got my current XMLHttpRequest
objects instantiating in try-catch blocks. (I found an article on the
net loong before I found the group)

~A!

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.

I'd like to thank all of you for your comments and suggestions.

I tried to give each one specific thought at attention. Although I
rejected a few ideas here and there that didn't fit with my desired goal,
they were still appreciated.

Following the Mantra of 'Release Early. Release often.' I offer my second
draft for discussion.

If your title bar does not indicate version 0.2, reload the page. Usually
the F5 key on most browsers, or the 'reload' button.

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

Jeremy J Starcher posted :

If your title bar does not indicate version 0.2, reload the page. Usually
the F5 key on most browsers, or the 'reload' button.

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

Additionally, the little-known CTRL-F5 that will defeat the cache (at
least in IE and FF)

Thanks, Jeremy!

~A!

Anthony Levensalor wrote:

David Mark posted :
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.

This is an excellent tip, thanks!

It's a recipe for disaster. Whenever you use scripts that use try..catch
as-is, compilation will fail with a SyntaxError. Compilation of the other
scripts, that you use along with them and that don't use try..catch, is not
guaranteed. It does not matter at all whether script A uses features that
are defined in script B, compilation is done in order of inclusion. Since
loading script resources dynamically is error-prone, the best thing you can
do for now is a) to avoid try...catch entirely or -- where that is not
possible or feasible, such as in XHR scripts -- b) to use eval to hide it,
what I proposed.

I've got my current XMLHttpRequest objects instantiating in try-catch
blocks.

And that is good so. However, it should be hidden as described.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann