469,326 Members | 1,359 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,326 developers. It's quick & easy.

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_Speculative_For_Discussion_OK?'>
1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another reality?
2 if (navigator.userAgent.indexOf("IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascript:somefunction()"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write("<p>Important 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 5174
In article <9A**************@merlyn.demon.co.uk>, Dr John Stockton
<sp**@merlyn.demon.co.uk> writes
JRS: In article <Hs**************@jgharris.demon.co.uk>, dated Thu, 23
Sep 2004 22:04:03, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted :

I know there are 10*22*22 square yards in an acre (well, except in US
Survey maps) as it's 1 chain by 1 furlong, but there's no good reason to
write the resulting number once, let alone twice.


No good reason *for you*.

<snip>

By now everyone realises, I hope, that this is a discussion about
different reasonable coding styles, not about good code and bad code.

To avoid any misunderstandings we should point out occasions when using
a number instead of a formula really would be bad : numbers like 2*pi,
square root of 3, and even simple fractions such as 1/3.

John
--
John Harris
Jul 23 '05 #101
JRS: In article <Li**************@jgharris.demon.co.uk>, dated Sat, 25
Sep 2004 20:50:13, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted :
In article <9A**************@merlyn.demon.co.uk>, Dr John Stockton
<sp**@merlyn.demon.co.uk> writes
JRS: In article <Hs**************@jgharris.demon.co.uk>, dated Thu, 23
Sep 2004 22:04:03, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted :

I know there are 10*22*22 square yards in an acre (well, except in US
Survey maps) as it's 1 chain by 1 furlong, but there's no good reason to
write the resulting number once, let alone twice.


No good reason *for you*.

<snip>

By now everyone realises, I hope, that this is a discussion about
different reasonable coding styles, not about good code and bad code.


No, it is more of a discussion of which constructs seen in code (whether
or not they are intrinsically reliable) can be taken as indicating an
increased probability that code on the page (whether or not including
the construct(s) seen) is unsound.

As an extreme example, the code line

// This page does not work properly.

is I believe perfect javascript; but it casts considerable doubt on the
rest of the page.

And the presence, in comment or string, of the characters '9/26/04' or
'color' strongly suggests that code purporting to calculate Week Number
is unfit for international use - the suggestion being weakened by the
presence of the characters 'ISO 8601'.

And mis-spelt text in an author's presumed native language is an omen of
carelessness.

Bad style, though certainly significant, is not the only bad sign.
Of course, most code on the Web works, apparently successfully, with at
least one browser; however bad the other signs are, that at least
suggests that the underlying method may be sound, if carefully
implemented.
Another class of bad sign is code which iterates to get to a state which
can easily enough be reached more directly. For the first Thursday of
next month incrementing the date until it is next month AND Thursday
is inefficient - one should go directly to the 7th of next month, do
something involving getDay, and go then to the date. The first is a
bad, but not fatal, sign.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #102
ji*@jibbering.com (Jim Ley) wrote in message news:<41****************@news.individual.net>...
On 22 Sep 2004 07:51:48 -0700, br*************@glic.com (bruce) wrote:
Being in a practical business environment,


Lots of us are in the same environment you know...
First off, I have deadlines. If some javascript works in IE5 and up
(we only support IE, 5.5 and up), and is not deprecated, I'm using it.


I would say that's negligent, javascript code costs more to maintain
than develop in my experience (assuming it's lifetime isn't measured
in months) Even IE specific code can be tough - every IE service
pack, every IE release, you'll likely turn up a few issues on every
5000 lines, some will be easy - some will kill an entire platform
requiring an entire rewrite (recently a win2k service pack managed to
kill document.write=chicken on IE5.5sp2 that hurt a client-side
rewriting proxy)

How you write something can minimise those maintenance costs -
especially important as you're fixing that against a broken live
system, much more dangerous than development where it doesn't matter
if it takes an extra you've not got clients using it yet.

Jim.

Hi Jim:
On the contrary, from reading this thread, I get the impression
that these people are NOT in a practical business environment, or else
they don't treat it as such.
While I do my best not to use hacks or work-arounds or
hidden-secrets, nor will I debate the finest nuances of javascript as
is done here in this thread. I don't have the time. I work on five
projects at once sometimes.
I'm much more concerned with writing clean code that I can come
back to and read and enhance. Seems like many others before me at my
company more resembled what I read in this thread: people willing to
write messy, unreadable code, just because it is theoretical "best
practices". Such a policy would probably get me fired.
If you call such work negligent, well, at least I still have a
job. The other way, I'd be un-negligent, and quite un-employed. That's
my real world.
Jul 23 '05 #103
Richard Cornford wrote:
href="javascript:somefunction()" - wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.


Intrinsic event handler attributes have been introduced in HTML 4.01 and
will not work in HTML 3.2 user agents, while a `javascript:' URI will work.
Exactly the informed/experienced will use the above construct to support
HTML 3.2 user agents, too, i.e. your statement is false. Authors
presenting visual hyperlinks for bookmarklets will also use javascript:
URIs in their source code.

The presence of javascript: URIs in source code alone cannot be considered
an indicator for bad style; that depends on the context. At the most such
a snippet indicates that the source code requires a more thorough
inspection (whether the snippet makes sense in that context or not).
PointedEars
--
Is that all you got? Yo JavaScript should be JavaScrapt, you think HTML
means HotMail... and don't even get me STARTED talking about yo
mamaboard!!!
Jul 23 '05 #104
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
href="javascript:somefunction()" -wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Intrinsic event handler attributes have been introduced in HTML 4.01


They were not introduced, they were formalised, and in the December 1997
draft of HTML 4.0 according to the HTML specs. That does not mean that
they will be unavailable on HTML 3.2 user agents.
and will not work in HTML 3.2 user agents,
Then you can name those user agents?
while a `javascript:' URI will work.
Javascript URIs have never worked on UAs that do not support scripting
with javascript.
Exactly the informed/experienced will use the above
construct to support HTML 3.2 user agents, too,
No they won't. The attempt would not result in clean degradation on
unscriptable HTML 3.2 UAs (probably the majority of such browsers) and
currently active scripted support for such ancient browsers (assuming
you actually can name a single example of a scriptable HTML 3.2 UA that
would not understand onclick in a context where it would understand
href="javascript: ... ") is below the threshold of real world and
commercial scripting (so clean degradation on those UAs if the
preferable option).
i.e. your statement is false.
Not as worded.

<snip> The presence of javascript: URIs in source code alone
cannot be considered an indicator for bad style;
HTML source code is specified in my statement.
that depends on the context.

<snip>

The context of providing bookmarkable javascript URIs is the only
reasonable example of there use in HTML and it is not exactly common or
likely to be the area in which assessing the badness of a script is
applicable.

Richard.
Jul 23 '05 #105
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
href="javascript:somefunction()" -wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad. Intrinsic event handler attributes have been introduced in HTML 4.01


They were not introduced, they were formalised, and in the December 1997
draft of HTML 4.0 according to the HTML specs. That does not mean that
they will be unavailable on HTML 3.2 user agents.


The fact that "It is inappropriate to use W3C Working Drafts as reference
material or to cite them as other than 'work in progress'." aside[1],
"HTML 3.2 aims to capture recommended practice as of early [19]96 [...]"[2]
Therefore, it is, on the contrary, highly likely that HTML 3.2 user agents
do not support intrinsic event handler attributes.

[1] <http://www.w3.org/TR/WD-html40-970917/>
[2] <http://www.w3.org/TR/REC-html32>
and will not work in HTML 3.2 user agents,


Then you can name those user agents?


Probably, but I don't have to (prove anything regarding this matter).
while a `javascript:' URI will work.


Javascript URIs have never worked on UAs that do not support scripting
with javascript.


Of course not, and I have never claimed that the opposite is true.
However, code like

<script type="text/javascript">
document.write(
'<a href="javascript:foobar()" onclick="foobar();'
+ ' return false;">foobar<\/a>');
</script>

is possible and, even more, it provides a way of clean degradation.
Exactly the informed/experienced will use the above
construct to support HTML 3.2 user agents, too,


No they won't. The attempt would not result in clean degradation on
unscriptable HTML 3.2 UAs (probably the majority of such browsers)
[...]


It would, see above.
i.e. your statement is false.


Not as worded.


Of course as worded.
<snip>
The presence of javascript: URIs in source code alone
cannot be considered an indicator for bad style;


HTML source code is specified in my statement.


Writing HTML source code is possible with client-side scripting.
You stated that the above source code "wouldn't appear in HTML
written*by*the*informed/experienced" which is obviously false.
that depends on the context.

<snip>

The context of providing bookmarkable javascript URIs is the only
reasonable example of there use in HTML [...]


No, it is not.
PointedEars
--
If at first you don't succeed, call it version 1.0
Jul 23 '05 #106
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
and will not work in HTML 3.2 user agents,


Then you can name those user agents?


Probably, but I don't have to (prove anything regarding this matter).


Then I will say, without any formal backing either, that there are
*no* HTML 3.2 agents (being a client that understands only HTML 3.2
and not HTML 4). If there is a client that understands both Javascript
and HTML 3.2, then it also understands intrinsic event handlers.

Ofcourse, a negative is hard to prove, so I won't :)

Ok, a little research:
IE 3 was a HTML 3 browser, not 3.2. No scripting.
IE 4 supports intrinsic event handlers.
Netscape 2 supports intrinsic event handlers.
Opera 3.21 supports intrinsic event handlers.
That is, for each of these browsers, the first major version to
support scripting at all, also supports intrinsic event handlers.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #107
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
href="javascript:somefunction()" -wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.

Intrinsic event handler attributes have been introduced in
HTML 4.01
They were not introduced, they were formalised, and in the December
1997 draft of HTML 4.0 according to the HTML specs. That does not
mean that they will be unavailable on HTML 3.2 user agents.


The fact that "It is inappropriate to use W3C Working Drafts as
reference material or to cite them as other than 'work in progress'."
aside[1], "HTML 3.2 aims to capture recommended practice as of early
[19]96 [...]"[2] Therefore, it is, on the contrary, highly likely
that HTML 3.2 user agents do not support intrinsic event handler
attributes.


Exactly how many scriptable web browsers existed in early 1996? One?

The point of referencing the December 1997 draft of HTML 4.0 is to show
a date by which it was considered worth formalising intrinsic event
handlers. It demonstrates that intrinsic events predate that draft. That
document's status does not modify its historical value in this respect.

<snip>
and will not work in HTML 3.2 user agents,


Then you can name those user agents?


Probably, but I don't have to (prove anything
regarding this matter).


In the event that there are no scriptable HTML web browsers that would
not understand an onclick event handler in a context where they would
understand href="javascirpt: ... " then your whole point is completely
worthless. As nobody else believes these browsers ever exited it is your
responsibility to back up your assertion by citing a (any) specific
browser. (You might still be asked why anyone scripting in 2004 should
be considering a browser that would have been minor nearly a decade ago,
but if no such browser exists there is no point even considering that.)
while a `javascript:' URI will work.


Javascript URIs have never worked on UAs that do not support
scripting with javascript.


Of course not, and I have never claimed that the opposite
is true.


Beyond the use of the words "will work" unqualified in the above
statement, referring to "HTML 3.2 user agents" (also unqualified).
However, code like

<script type="text/javascript">
document.write(
'<a href="javascript:foobar()" onclick="foobar();'
+ ' return false;">foobar<\/a>');
</script>

is possible and, even more, it provides a way of clean degradation.
But the javascript href is not in the HTML source code. It is within a
javascript string literal.
Exactly the informed/experienced will use the above
construct to support HTML 3.2 user agents, too,


No they won't. The attempt would not result in clean degradation on
unscriptable HTML 3.2 UAs (probably the majority of such browsers)
[...]


It would, see above.


If you put the javascript href in the HTML rather than the javascript
you cannot achieve clean degradation.
i.e. your statement is false.


Not as worded.


Of course as worded.


This is another example of your stubborn refusal to employ English as a
means of communication. What exactly do you think was the point of
including the letters HTML in the wording I used if it was not to draw a
distinction between types of source code? Your unwillingness to
co-operate in understanding what is clearly intended is a character flaw
that will strongly discourage people form talking to you at all.
<snip>
The presence of javascript: URIs in source code alone
cannot be considered an indicator for bad style;


HTML source code is specified in my statement.


Writing HTML source code is possible with client-side scripting.


I wrote: " ... appear in HTML written by the informed/experienced, ...",
not *written* by javascript.
You stated that the above source code "wouldn't appear in HTML
written by the informed/experienced" which is obviously false.


So are your considering javascript "the informed/experienced" as it is
doing the writing? (That is one of the problems with insisting on being
over-literal; it goes both ways, and you are no more capable of writing
statements in English that are truly unambiguous than anyone else is.)
that depends on the context.

<snip>

The context of providing bookmarkable javascript URIs is
the only reasonable example of there use in HTML [...]


No, it is not.


If you don't suggest more contexts your argument is no more than your
usual "I am right and everyone else is wrong", and that is less than
convincing.

Richard.
Jul 23 '05 #108
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
> href="javascript:somefunction()" -wouldn't appear in HTML written
> by the informed/experienced, so
> can be stated as bad.
Intrinsic event handler attributes have been introduced in
HTML 4.01
They were not introduced, they were formalised, and in the December
1997 draft of HTML 4.0 according to the HTML specs. That does not
mean that they will be unavailable on HTML 3.2 user agents.


The fact that "It is inappropriate to use W3C Working Drafts as
reference material or to cite them as other than 'work in progress'."
aside[1], "HTML 3.2 aims to capture recommended practice as of early
[19]96 [...]"[2] Therefore, it is, on the contrary, highly likely
that HTML 3.2 user agents do not support intrinsic event handler
attributes.


Exactly how many scriptable web browsers existed in early 1996? One?


I don't know, I care less and the answer to this question is
completely unimportant regarding the discussed issue.

You are but unsuccessfully trying to escape the simple fact that
you cannot reasonably call something "bad style" if you don't know
about all the ways it can make sense.
However, code like

<script type="text/javascript">
document.write(
'<a href="javascript:foobar()" onclick="foobar();'
+ ' return false;">foobar<\/a>');
</script>

is possible and, even more, it provides a way of clean degradation.


But the javascript href is not in the HTML source code. It is within a
javascript string literal.


That J(ava)Script string literal contains HTML source code,
and this J(ava)Script source code generates HTML source code.
Exactly the informed/experienced will use the above
construct to support HTML 3.2 user agents, too,
No they won't. The attempt would not result in clean degradation on
unscriptable HTML 3.2 UAs (probably the majority of such browsers)
[...]

It would, see above.


If you put the javascript href in the HTML rather than the javascript
you cannot achieve clean degradation.


I write HTML with a javascript: URIs using JavaScript and can achieve
clean degradation for there are features that can only be accomplished
with client-side scripting and as such should be written dynamically.
PointedEars
--
Hmmm... Purple!
Jul 23 '05 #109
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>>href="javascript:somefunction()" -wouldn't appear in HTML written
>> by the informed/experienced, so
>> can be stated as bad.
> Intrinsic event handler attributes have been introduced in
> HTML 4.01
They were not introduced, they were formalised, and in the
December 1997 draft of HTML 4.0 according to the HTML specs.
That does not mean that they will be unavailable on HTML 3.2
user agents. <snip> ... Therefore, it is, on the contrary, highly likely that
HTML 3.2 user agents do not support intrinsic event handler
attributes.
Exactly how many scriptable web browsers existed in early 1996? One?


I don't know, I care less and the answer to this question is
completely unimportant regarding the discussed issue.


The historical context in which HTML 3.2 was written is very relevant to
exactly to what extent it would be "highly likely" that scriptable HTML
3.2 user agents would understand intrinsic events. As JavaScript
transitioned from beta to 1.0 around the turn of 1996 it is actually
highly likely that any subsequent HTML 3.2 browsers introduced with
scripting would have followed the example of Netscape 2 and implemented
intrinsic events regardless of the then current HTML spec.
You are but unsuccessfully trying to escape the simple fact that
you cannot reasonably call something "bad style" if you don't know
about all the ways it can make sense.


Who is trying to escape what here? (success or otherwise being best left
to others to judge.)

You started off arguing that javascript hrefs were a useful fallback for
HTML 3.2 user agents because it was "highly likely" that they would not
understand intrinsic events. That point evaporated when you realised
that no such browser ever existed. (Assuming that it has now dawned on
you that that is the case.)
However, code like

<script type="text/javascript">
document.write(
'<a href="javascript:foobar()" onclick="foobar();'
+ ' return false;">foobar<\/a>');
</script>

is possible and, even more, it provides a way of clean
degradation.


But the javascript href is not in the HTML source code.
It is within a javascript string literal.


That J(ava)Script string literal contains HTML source code,
and this J(ava)Script source code generates HTML source code.

<snip>

So the dispute is reduces to nothing more than your refusal to
comprehend that the wording "appear in HTML" was intended to draw
precisely this distinction. HTML written by javascript appears in
javascript source code not HTML. Otherwise there would have been no
point in my mentioning HTML at all.

Richard.
Jul 23 '05 #110

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.