473,696 Members | 1,675 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Top warning signs of bad code?

It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.

I was looking through the JS FAQ for any question that
identifies the warning signs to look out for, the things
that most easily and clearly identify the author of code
as something less than a master of the art.

I did not find an FAQ that answered it, but I think the FAQ
should contain the info., so, here is my proposed list..

<FAQENTRY class='more_Spe culative_For_Di scussion_OK?'>
1 <SCRIPT LANGUAGE='JavaS cript'> // last millenium, or another reality?
2 if (navigator.user Agent.indexOf(" IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascrip t:somefunction( )"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write( "<p>Importa nt content.."); // delivering content.
</FAQENTRY>

What is your opinion? Are these the top 7?
Which 28 did I miss?

Also, why does the FAQ not contain the words "degrade",
"graceful" or "noscript" (I guess I might have been
looking for the wrong term with the first two, but
no mention of NOSCRIPT? That surprised me.)

BTW - The Jibbering JS FAQ is the single greatest FAQ*
I use, but I just have a hankerin' to get mentioned in
it, or at least contribute to it. ;-)

* I have my own (fledgling) Java FAQ that I hope might
approach the quality of the JS FAQ one day, and am a
contributor to the recently expanded and improved
c.i.w.a.s. FAQ.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane
Jul 23 '05
109 5881
>>Keep in mind that it detects *probable* errors.
A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".

Could you provide some concrete examples Lee?

I would want to make note of, and provide some
examples of 'false positives'.


From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT.

http://www.crockford.com/javascript/lint.html
Jul 23 '05 #41
On Tue, 21 Sep 2004 06:28:10 -0700, Douglas Crockford wrote:
From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns.


Are they flagged as errors or warnings Douglas?

Is there any significant dissension to JSLint's
identifcation of errors alone?

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane
Jul 23 '05 #42
Lee
Douglas Crockford said:
Keep in mind that it detects *probable* errors.
A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".


Could you provide some concrete examples Lee?

I would want to make note of, and provide some
examples of 'false positives'.


From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT.


There are few sloppy coding practices that are as dangerous
as taking well-tested code and modifying it to remove a "faulty"
coding pattern.

Even if we accept the statement that all code is improved by
conforming to your tool, that doesn't mean that code that doesn't
conform should be blindly and automatically labeled as "bad".

Many of the rules that JSLINT enforces are intended to prevent
confusion on the part of future readers. Proper documentation
is an alternative to conformity. The fact that your tool cannot
detect proper documentation should not rule it out.

I would not ban the comma operator in all cases. Unfortunately,
it would be difficult for your tool to detect only the cases
that are likely to be confusing. The following, while not best
practice, should not cause an entire script to be rejected as
bad code:

for(i=1,j=0;j<a lpha.length;i++ ,j++)

Uppercase HTML tags are not a sign of bad code. Out of date,
perhaps, but not to be automatically flagged as a bad example.

Labels of which you disapprove are not necessarily a sign of
bad code. I've known people to use labels where most of us
would use comments, to flag special blocks of code.
The labels are not used in the code. It's a harmless quirk.

Using labels that match variable names should not automatically
be rejected. You need to actually look at the code and apply
judgment to decide if the usage is potentially dangerous.

There are probably more examples. These are just from my memory
of having read the description of JSLINT. The bottom line is
that LINT-like tools are very handy for the developer to use to
identify code that may be confusing, but the tool lacks judgment
to decide whether each case is actually dangerous code.

Jul 23 '05 #43
JRS: In article <iv************ ********@gigane ws.com>, dated Mon, 20
Sep 2004 23:26:21, seen in news:comp.lang. javascript, jmm-list-gn <jmm-
li***********@s ohnen-moe.com> posted :
Dr John Stockton wrote:

Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.

Er. "There" should be "their".


Yes. The <G> was to show that I did it on purpose, having noted that
the previous poster had done it (for reasons unknown) in the first
paragraph that I had quoted. PKUATBT.

--
John Stockton, Surrey, UK. ??*@merlyn.demo n.co.uk Turnpike v4.00 MIME.
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Jul 23 '05 #44
JRS: In article <ci************ *******@news.de mon.co.uk>, dated Tue, 21
Sep 2004 01:36:50, seen in news:comp.lang. javascript, Richard Cornford
<Ri*****@litote s.demon.co.uk> posted :
Getting back to the subject of this thread. eval(' ... '); - so exceptionally valid that
it can be stated as bad.
Disagree :
(a) in objecting, ISTM unreasonable to object to a string literal but
not to a string expression.
(b) where eval() is used validly, ISTM fairly likely that at least some
other parts of the page will be either better than average or rare valid
examples.
Suggest eval(...) usually, but not always, bad
href="javascri pt:somefunction ()" - wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Has it *no* proper use?

Failing to degrade to a viable
web page (for any reason including
the absence of script support) - easily objectively tested and
certainly bad.


Counter-example - my page holidays.htm. Originally, I wrote it in pure
HTML; but that expanded and needed annual tiresome updating, which I
decline to do. Other than its viable links, the page is of negligible
value without javascript. Of course, "viable" is subjective; the
scriptless page is a valid page.

If Notes-length, the document might, in regard to assumptions, observe
that a document *designed* for a limited audience may nevertheless be
visible more widely; it should not be over-criticised for not being
entirely successful for the widest audience. Consider, perhaps, a page
expertly written by the RNIB for a non-sighted audience (I know the RNID
[D!=B] has an expert); it might not work well in MSIE<latest>.
Note also that code copied, for example from a FAQ, is not a good guide
to the quality of original code on the same page; and vice versa.
Note that the conditions which should apply to the design of
"commercial " sites, especially those used to implement some sort of
purchase agreement, do not necessarily apply equally to other types of
site, such as academic, technical, or vanity sites.

--
John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demo n.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Jul 23 '05 #45
On Tue, 21 Sep 2004 12:00:53 +0100, Dr John Stockton wrote:
JRS: In article <iv************ ********@gigane ws.com>, dated Mon, 20
Sep 2004 23:26:21, seen in news:comp.lang. javascript, jmm-list-gn <jmm-
li***********@s ohnen-moe.com> posted :
Dr John Stockton wrote:

Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.
Er. "There" should be "their".


Yes. The <G> was to show that I did it on purpose, having noted that
the previous poster had done it (for reasons unknown) ..in the first
paragraph


* Aha! I could not quite figure what you meant either,
but I decided long ago that language is for communication,
and that I would stress over my use of it, only if the person
to whom I was communicating did not understand me.
..that I had quoted. PKUATBT.


I *prefer* hanging at the back, the atmosphere is more relaxed,
and it means you usually miss the rain of poison-darts from
the natives during ambushes.

So their! :-P

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane
Jul 23 '05 #46
In article <1x************ *************** ***@40tude.net> , Andrew
Thompson <Se********@www .invalid> writes

<snip>
Whereas '==true' contrasts to the 'solid script doing stupid things'
by being the (slightly) inept way of doing things which may be
quite sensible.

I would tend to consider it an indication the author's knowledge
could not be trusted. I think I'll count votes on this one in the end..

<snip>

Some good programmers in other languages think that the '== true' style
makes things clearer and easier to proof-read.

So, on its own it says nothing about the code but if there are other
horrors then it adds to the horror.

John
--
John Harris
Jul 23 '05 #47
In article <1n************ *************** **@40tude.net>, Andrew Thompson
<Se********@www .invalid> writes
On Mon, 20 Sep 2004 16:49:54 +0100, Dr John Stockton wrote:
<snip>
Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000;

There's a well known rule that you must never, ever, ask the user to
calculate something the computer can calculate. This also applies to
programmers. 24*60*60*1000 is easy to understand, easy to proof-read,
and unlikely to be mis-calculated. In addition it will sometimes provoke
the programmer into remembering that some days aren't 24 hours long and
that some minutes aren't 60 seconds long, which is good.

What is bad is when 24*60*60*1000 appears more than once in the same js
or html file.

<snip>I am not quite convinced that an ..approximate
date is unacceptable in a lot of the many (seemingly
quite trivial) situations in which it is used.

<snip>

What is bad for people picking up the code is where there is no comment
saying it's an approximation. Unfortunately, a beginner is unlikely to
know how to check this :-(

John
--
John Harris
Jul 23 '05 #48
JRS: In article <1n************ *************** **@40tude.net>, dated
Tue, 21 Sep 2004 11:12:22, seen in news:comp.lang. javascript, Andrew
Thompson <Se********@www .invalid> posted :
Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000; use
of that number in a manner which will fail across Summer Time changes,
or away from GMT.
Richard also expressed that such rough-shod dealing
with dates was bad form, but..

If I wanted to know the dividend of a share that matures
Feb. 1st 2005, I would want it accurate to the cent.


If preparing data in advance for checking up on your accounts, yes. If
deciding whether the dividend would allow you to buy a new piece of
furniture, probably not.

OTOH, if one of my relatives had a page that reported their
kid was '108 days old' I would shrug and reply, "..whatever ,
get back to me when it stops drooling".

I am not quite convinced that an ..approximate
date is unacceptable in a lot of the many (seemingly
quite trivial) situations in which it is used.
Error in a calculation in which correctness is not difficult is not of
itself unreasonable; but it casts a shadow over the estimated quality of
the rest of the code. A rough calculation accompanied by
"approximately" , visible on the page or in comment, is probably a *good*
sign, unless the exact calculation is really easy.

Perhaps my perception of most date scripts being used
for trivial ends is quite incorrect? How much of it
is going on behind the scenes that is not immediately
apparent to the web-surfer?


Who knows? But if something for trivial ends is worth doing, it is
worth doing right, where that is not difficult.
Code which is being presented for others to copy should be exactly
right, since the author does not know what it may be used for. For age
in days (of one born at 00:00:00) :

alert(Math.floo r((new Date() - new Date("2004/01/09"))/864e5) +
" days")

is bad; but

alert(Math.floo r((new Date() - new Date("2004/01/09"))/864e5) +
" days, approximately")

is good.
alert(Math.floo r((new Date() - new Date("09/01/2004"))/864e5) +
" days")

is very bad indeed, though worse is possible.

***

There is an ambiguity in the initial article of the thread, which
suggests that : most people get their JS off web sites, which is
entirely logical.

Aside : I deprecate that abbreviation, but point
out that for myself I *always* use "JRS"
(unless J or S alone serves in context).

Does "web sites" mean web sites in general, or web sites that claim in
some way to be FAQs or tutorials? Are we referring to copying code that
is offered in order that it may be copied, or code that is present
merely to be executed?
Some FAQ sites are basically reliable; others are mere copies of all the
code that the owner can get (a fairly well-known site has without
permission copied some of my code, and done so badly). Some non-FAQ
sites are reliable (W3's, I guess, for example); others are not (HMGs',
I guess).
FAQ sites should be of moderately consistent quality; less so for
"collect anything" and multi-author ones.

But sites intended only to be executed may be of very varying quality; a
page may contain code copied from our FAQ itself, some from a bad
"compendium " site, and some written by the page author. Therefore, the
quality of one part of a page or site may be a poor guide to the quality
of other parts.

--
John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Delphi 3 Turnpike 4
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.co m/CompLangPascalD elphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
Jul 23 '05 #49
>>From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT.
There are few sloppy coding practices that are as dangerous
as taking well-tested code and modifying it to remove a "faulty"
coding pattern.
Bad code is not made good by ignoring its defects. "It seems to work" is
way too low a standard, especially in a runtime environment as variable
and deficient as web browsers.
Even if we accept the statement that all code is improved by
conforming to your tool, that doesn't mean that code that doesn't
conform should be blindly and automatically labeled as "bad".
Code which can be improved is sub-good. Can we agree on that?
Many of the rules that JSLINT enforces are intended to prevent
confusion on the part of future readers. Proper documentation
is an alternative to conformity. The fact that your tool cannot
detect proper documentation should not rule it out.
Bad code is not made good by commenting.
I would not ban the comma operator in all cases. Unfortunately,
it would be difficult for your tool to detect only the cases
that are likely to be confusing. The following, while not best
practice, should not cause an entire script to be rejected as
bad code:

for(i=1,j=0;j<a lpha.length;i++ ,j++)

Uppercase HTML tags are not a sign of bad code. Out of date,
perhaps, but not to be automatically flagged as a bad example.
JSLINT has an option to ignore HTML case.
Labels of which you disapprove are not necessarily a sign of
bad code. I've known people to use labels where most of us
would use comments, to flag special blocks of code.
The labels are not used in the code. It's a harmless quirk. Using labels that match variable names should not automatically
be rejected. You need to actually look at the code and apply
judgment to decide if the usage is potentially dangerous.
These are reckless practices that are never seen in good code.
There are probably more examples. These are just from my memory
of having read the description of JSLINT. The bottom line is
that LINT-like tools are very handy for the developer to use to
identify code that may be confusing, but the tool lacks judgment
to decide whether each case is actually dangerous code.


Code which is confusing is dangerous.

http://www.crockford.com/javascript/lint.html
Jul 23 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.