RFD: How To Recognize Bad Javascript Code

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.

In article <477bded9$0$9156$607ed4bc (AT) cv (DOT) net>, "John W. Kennedy" <jwkenne (AT) attglobal (DOT) net> wrote:

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

No, it's not. It may have been at one time, but that is not its meaning now.

....this proves nothing but that your reading is restricted.

It proves, at least, that my reading includes contemporary dictionaries,

whereas yours appears to be limited to those some seven or eight decades old.
The plain fact is that the word does not now have the meaning you insist on
attaching to it. Whether it ever did is irrelevant.

On Tue, 01 Jan 2008 15:14:45 -0500, Anthony Levensalor wrote:

I'm just heading down that "re-learning everything I thought I knew"
path in Javascript because of that and sites like it. Thanks for not
wanting anyone else to go through this, it's not fun.

Just talk everyone into sending me $US10.00 and I'll start writing a good
book/website. That way, we can put sites like that out of business.

Who knows, maybe take one of those sites and match it script for
script.

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,
I eyeball the code for any of the things I mention here. If I find any
of these coding 'features' I skip that code and move onto the next one.

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.

(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*)

On a more serious note, I've thought about a 'Best Practices' type of
document. I'd say things like:

All variables declarations should be before any code. This reminds the
coder that { code blocks } do not have their own scope. Seems a lot of
people like lazy/delayed declaration. Declare it when you need it.

The discussion would be ... entertaining. And I wouldn't even *really*
be trolling.

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.

On Jan 2, 9:24*am, Gregor Kofler <use... (AT) gregorkofler (DOT) at> wrote:

John W. Kennedy meinte:

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.

ACK. Well, as a non-native speaker I don't have the insights of JWK... I
have to rely on dictionaries.

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.

So what? Names, meanings, words have changed throughout centuries
because of errors in translation or simple typos. Being a percevtive
person, you've probably realised that the year is 2008. (You should move
to Iceland - their language hasn't changed over the last thousand years.
Well, at least only very slightly.)

Icelandic has changed a lot in the last 1000 years, but it has not
lost the similarities to the language as it was 1000 years ago. That
means Icelanders are able to read the Saga litterature while still
having the ability to write about the newest technological advances in
their own language without having to borrow words from other languages.

Gregor Kofler wrote on 03 jan 2008 in comp.lang.javascript:

It is. According to all my dictionaries (online and printed),
"deprecate" and "depreciate" have different meanings (the latter one is
only used in financial contexts).

Indeed:

deprecate verb (deprecated, deprecating)

to express disapproval of something;
to deplore something.

ETYMOLOGY: 17c, originally meaning 'to pray against evil':
from Latin deprecari 'to try to avert'.

DE 'un' + PRECOR 'to pray, to ask'

=============

depreciate verb (depreciated, depreciating)

1 to fall, or make something fall, in value.

2 to be contemptuous of the worth of something;
to belittle someone or something.

ETYMOLOGY: 15c: from Latin depretiare 'to lower the price of'.

DE 'un' + PRETIUM 'price'

Webpages tend to have a worldwide
readership and are not restricted to a small circle of linguists, and
it's wise to stick to the proper contemporary meaning of words.

Far more important is that the words are different, have a differnt
meaning, and stem from different Latin root words.

Your 'small circle of linguists' has the responsability to advice the
correct and logical use of words, especially in the strict sense of
definitions like Javascript specs.

This is certainly NOT off topic in this NG.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

On Tue, 1 Jan 2008 at 18:01:51, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

<snip>

a) not every line should be ended with a semicolon but every *statement*;
snip

That last bit is untrue. I'm surprised that someone who often quotes
ECMA 262 should misunderstand statements so badly.

In fact there are three ways statements can end ...

1 They can end with a nested, smaller, statement.
E.g. if statements and while statements.

2 They can end with a close curly bracket, }.
E.g. block statements {...}, and switch statements.

3 They can end with a semicolon.
E.g. do-while statements, expression statements.

John
--
John Harris

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

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.

Fair enough.

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,
I eyeball the code for any of the things I mention here. If I find any
of these coding 'features' I skip that code and move onto the next one.

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.

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?

(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

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

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/c532483403801387/738bf21b7896d015?lnk=gst&q=matt+kruse+best+practic es#>

And it was 137 posts deep.

I didn't find a version 2 post but I didn't look long.

Any "Best Practices" or a "Bad Practices" document is going to be a
reflection of the person who wrote it. That means you have to make up
your own mind, on your own beliefs, and go with it.

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.

On a more serious note, I've thought about a 'Best Practices' type of
document. I'd say things like:

All variables declarations should be before any code. This reminds the
coder that { code blocks } do not have their own scope. Seems a lot of
people like lazy/delayed declaration. Declare it when you need it.

And I would be one of the ones that disagrees with that. I want them
declared as close to where they are being used as possible.

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

Evertjan. said the following on 1/3/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.

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