473,696 Members | 2,003 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 5884
On Mon, 20 Sep 2004 12:40:33 -0400, Randy Webb
<Hi************ @aol.com> wrote:
Matt Kruse wrote:
I'd like more info about this. Do you have a test case?

In my version of IE6 - which is completely up-to-date except for SP2 - I can
do a document.write( ) to an iframe document without any problems.


<script type="text/javascript">
function changeIFrame(){
myIFrame.docum ent.write('new Content')
myIFrame.close ()
}

<body onload="changeI Frame()">

<iframe src="javascript :'<body>test</body>'" id="myIFrame"
name="myIFRame ' onload="alert(t his.src)"></iframe>

Seems to work in IE6 SP2 on WinXP SP2.

So I am not sure what Jim is alluding to.


I'll see if I can dig up a test case, but as my reserve laptop's
screen just broke aswell as my main one, it may take awhile...

You're replacing the content there, though, maybe it was calling
methods...

Jim.
Jul 23 '05 #31
Jim Ley wrote:
On Mon, 20 Sep 2004 12:40:33 -0400, Randy Webb
<Hi************ @aol.com> wrote:
<--snip-->
So I am not sure what Jim is alluding to.

I'll see if I can dig up a test case, but as my reserve laptop's
screen just broke aswell as my main one, it may take awhile...


Yikes!
You're replacing the content there, though, maybe it was calling
methods...


Maybe. If you can dig up the test case, I don't mind testing it to make
sure its an SP2 issue. I have both a non-updated and an updated XP that
I can test on to compare the two results.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq
Jul 23 '05 #32
Andrew Thompson wrote:
Richard Cornford wrote: <snip> Were you saying recently that even NN 4.78 was
conducive to element display/hide using JS?


Netscape 4 allows CSS positioned (absolute and relative) elements and
its LAYER and ILAYER elements to be hidden and shown, and their content
to be re-written (but not read.). But the Netscape 4 DHTML model is so
different form current browsers that these days it probably isn't worth
the effort to design DHTML for active Netscape 4 support (and with
sensible degradation designed in that still isn't the end of the world
for those that are still using Netscape 4).

<snip>
Browser detecting by object inference should be included.


Do not recall seeing the term, but I think I can guess
what it means, I will research it a bit further.


It was actually coined by Lasse Reichstein Nielsen to express (in part)
the style of browser detecting that makes conclusions about a browser's
entire object model based on tests applied to a few (and often only one)
feature of that browser. I use it because the term 'object detecting'
has (erroneously) been applied to that style of browser detecting in
addition to real feature detecting. So to avoid confusion I don't use
'objet detecting' to label anything, preferring the more specific and
descriptive terms.

It is also applied to structures such as:-

if(document.ima ges){
x = new Image();
x.src = 'img.gif';
}

- where the existence of the - Image - constructor is *inferred* from
the existence of the - document.images - collection. While true feature
detection would require that the existence of the - Image - constructor
should be directly verified with - if(window.Image ) - and the like,
prior to the use of the constructor, because the obvious one-to-one
relationship in that test virtually guarantees the safe execution of the
code that it guards.

<snip>
Degradation, clean, graceful or otherwise, is a script
design issue that probably goes beyond what is
appropriate in the quick answers section.


<musing>
Maybe it should be mentioned in a section, perhaps
combined with accessibility(? )
</musing>

<snip>

I wish it could be a simple as just mentioning script design and
accessibility. Both huge subjects about which little has been
pinned-down to the extent that any form of rules could be applied (as
opposed to general advice and guidelines).

Getting back to the subject of this thread. You are proposing we create
a list of telltale indicators of bad scripts. Presumably as guidance for
those not knowledgeable/experienced enough to apply their own judgement.
That is a bit of a problem in itself as it means that those indicators
should not require too much technically informed interpretation (else
they become unnecessarily).

LANGUAGE='JavaS cript1.2' - always bad.

browser detection (by any means) - always bad.

eval(' ... '); - so exceptionally valid that
it can be stated as bad.
href="javascrip t:somefunction( )" - wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Failing to degrade to a viable
web page (for any reason including
the absence of script support) - easily objectively tested and
certainly bad.
Failing to adapt to variables
known to be beyond the control
of a script author (font size
and the like) - easily objectively tested and
probably bad.
Crippling the normal browser
functionality - difficult to ever justify so bad.
However:-
Insufficiently defensive
scripting - not an easy judgement for someone
who hasn't learnt how to do it
themselves.

JSLINT - errors are bad, warnings take a bit
of judgement (It is not often that
I do things that JSLINT would flag,
but when I do it is informed and
intended).
Functional but
sub-optimal (24*60*60*1000)
or perverse (x.checked == true)
scripting - difficult to generalise about for the
inexpert, and inappropriate to
explicitly list.

If the intention is to provide the inexperienced with criteria for
identifying scripts that they should not consider examining as a
learning exercise, or deploying on a public web site, then the criteria
should be clear and easy to identify and test. That probably means
avoiding any attempt to build a comprehensive list and instead
concentrating on those things that provide the most (and most useful)
discrimination with the least need to judge and interpret the results of
tests.

Otherwise we are looking at a more in-depth document with guidance on
the application of the criteria and the interpretation of the results
(not impossible but also not a quick answer). As usual the optimum
solution would be a combination of the quick and simple and a more
in-depth document covering all the points raised, but it would help to
determine (agree upon) the best candidates for the quick answers entry.

Richard.
Jul 23 '05 #33
Lasse Reichstein Nielsen wrote:
Richard Cornford writes:
<SCRIPT LANGUAGE='JavaS cript1.2'> - is more indicative
of out of date and ill-informed authoring.


Definitly, that goes from just bad to directly dangerous.
...
as the LANGUAGE attribute will never directly harm a
script in an HTML browser in itself.


Sure it will. Try running the following in Mozilla and IE,
and wonder why they give different results.

<snip>

I was thinking in terms of the language attribute as in Andrew's
original example, though I could have expressed that better. With the
language version (and particularly 1.2) it certainly has the potential
for harm.

Richard.
Jul 23 '05 #34
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".

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
Jul 23 '05 #35
On 20 Sep 2004 09:18:38 -0700, Lee wrote:

(JSLint)
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'.

--
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 #36
On Tue, 21 Sep 2004 01:36:55 +0100, Richard Cornford wrote:
Lasse Reichstein Nielsen wrote:
Richard Cornford writes:
<SCRIPT LANGUAGE='JavaS cript1.2'> - is more indicative
of out of date and ill-informed authoring.
as the LANGUAGE attribute will never directly harm a
script in an HTML browser in itself.


Sure it will. Try running the following in Mozilla and IE,
and wonder why they give different results.

<snip>

I was thinking in terms of the language attribute as in Andrew's
original example, though I could have expressed that better.


OK (though invalid) <SCRIPT LANGUAGE='JavaS cript'>
Bad always <SCRIPT LANGUAGE='JavaS cript1.2'>

The warning list would need to stress the
distinction between the two, and while I see
the point about invalid attributes not causing
harm, I am uncomfartable with -not- pointing out
invalid HTML..

OTOH, it seems the "LANGUAGE='Java Script'" does
go beyond the scope of filtering out bad scripts.

--
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 #37
On Tue, 21 Sep 2004 01:36:50 +0100, Richard Cornford wrote:
Andrew Thompson wrote:
Richard Cornford wrote: <snip>
Were you saying recently that even NN 4.78 was
conducive to element display/hide using JS?


Netscape 4 allows CSS positioned (absolute and relative) elements and
its LAYER and ILAYER elements to be hidden and shown,


( Just to go a little off topic for a moment )
Excellent, that was all I am requiring of it
for my uses, but...
..But the Netscape 4 DHTML model is so
different form current browsers that these days it probably isn't worth
the effort to design DHTML for active Netscape 4 support ..


I take it (hope that) 'active Netscape 4 support' is
referring DHTML beyond showing/hiding elements?

--
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 #38
On Tue, 21 Sep 2004 01:36:50 +0100, Richard Cornford wrote:
Andrew Thompson wrote:
Richard Cornford wrote: ....
Browser detecting by object inference should be included.
...
It was actually coined by Lasse Reichstein Nielsen to express (in part)
the style of browser detecting that makes conclusions about a browser's
entire object model .... if(document.ima ges){
x = new Image();
x.src = 'img.gif';
}
OK, got it. Yes, I agree.
<snip> Degradation, clean, graceful or otherwise, is a script
design issue that probably goes beyond what is
appropriate in the quick answers section.
<musing>
Maybe it should be mentioned in a section, perhaps
combined with accessibility(? )
</musing>

<snip>

I wish it could be a simple as just mentioning script design and
accessibility. Both huge subjects about which little has been
pinned-down to the extent that any form of rules could be applied (as
opposed to general advice and guidelines).


I will have a look through the FAQ for such things,
if I do not feel they cover it, I might draft
something myself for Jim's consideration.

But then it would probably become quite a long article,
mostly about HTML, CSS and general UI design, so it might
be better to host it at my own site and suggest it as a link.
Getting back to the subject of this thread. You are proposing we create
a list of telltale indicators of bad scripts. Presumably as guidance for
those not knowledgeable/experienced enough to apply their own judgement.
That is a bit of a problem in itself as it means that those indicators
should not require too much technically informed interpretation (else
they become unnecessarily).
Yes, if it comes down to a degree of expertise to make
a judgement, it is not really suitable for the list.

Crippling the normal browser
functionality - difficult to ever justify so bad.
Several posters have poinetd out to me that something
that is bad for UI design or useability is not necessarily
a poorly written script, which is a good point.

I am torn between including things which are just plain stupid,
*or* strictly limiting it to script that is shoddily written.
<snip> JSLINT - errors are bad, warnings take a bit
of judgement
I think it might be best to include it as first,
but note it is the *errors* that are a dead giveaway.

<snip> Functional but ... .... or perverse (x.checked == true)
scripting - difficult to generalise about for the
inexpert, and inappropriate to
explicitly list.


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

Thanks for the further comments Richard..

--
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 #39
On Mon, 20 Sep 2004 16:49:54 +0100, Dr John Stockton wrote:
JRS: In article <yc************ *************** **@40tude.net>, dated
Sun, 19 Sep 2004 23:42:04, seen in news:comp.lang. javascript, Andrew
Thompson <Se********@www .invalid> posted : ...
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.


On the whole, agreed.


I must admit I am now tending against this one.

As a simple statement to someone assessing a script,
it is more often wrong than write, ...right. ;-)
7 document.write( "<p>Importa nt content.."); // delivering content.


Such a line is valid as the beginning of a section of computed content.


Well.. I don't know what to say here, how about..
7 document.write( "<p>Importa nt content that is not computed.."); //
delivering content.

But *damn* *it* that line wraps.. (VBG)

My point here, is that while several people have criticized
it, I also have a hankering to hear how they might phrase it.
Use of getYear, especially if combined with unreliable "century" code,
and more so if that code fails for dates after 1999.
Yup. I was waiting to hear something from you on dates. :)
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.

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.

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?

--
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 #40

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.