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  5721 
Douglas Crockford said: 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.
I said "well-tested", not "seems to work". Fixing code that isn't
broken, simply to pass an automated test, is reckless.
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?
Absolutely not. It's simply not perfect. 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.
If the only "deficiency" is that the meaning is not clear,
then commenting it certainly does correct that deficiency. 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<alpha.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.
Very rarely seen. What makes it reckless? The standard says
that the name space is separate. Every major browser complies.
Is it reckless to believe that they will continue to comply? 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.
Certainly. You missed the point that your software cannot
identify whether or not a particular usage is confusing.
Lee wrote:
I said "well-tested", not "seems to work". Fixing code that isn't
broken, simply to pass an automated test, is reckless.
Excuse me, but what is the difference? A script (or program) that is
"well-tested" has presumably executed sucessfully in a (large) set of
more or less artificial states. The larger the set, the better is the
test.
"seems to work" seems to cover this nicely.
--
Henrik
On Tue, 21 Sep 2004 22:19:04 +0100, Dr John Stockton wrote:
(A lot of interesting points re date calcs.
snipped - I'll have to mull those over) Does "web sites" mean web sites in general, or web sites that claim in
some way to be FAQs or tutorials?
I was thinking most specifically of 'web sites in general'
Various times I was surfing Sun's (+ others) site and noticed
they had achieved some effect I was interested in, so I dive
straight into the source and get the J(!R)S they use.
Sun (especially) excels at producing some extremely poor
Javascript. I have seen browser-sniffing JS, JS based
menus that would not degrade gracefully, and instances
where Sun thinks they can better guess which element on
a web-page should have focus, than the user's own browser.
I am not that familiar with the 'code archive' type sites
for JS, but I imagine that if somebody collected together
'a bunch of kewl scripts that work great*' ( * in their IE)
they might end up with some very broken scripts on the site.
Since they are specifically distributing scripts, the
potential damage is much greater.
--
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
On 2004/09/20 00:42, in article yc*****************************@40tude.net,
"Andrew Thompson" <Se********@www.invalid> wrote: 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.
The things I look for are well-organised code with meaningful variable and
function names and adequate comments. I prefer to see code written clearly
rather than concisely. I am not so concerned with the use a deprecated
constructs, though I would rather they were avoided. I am not so worried
about statements like "if (x == true)". The main thing is it is clear to the
reader. But before my head gets ripped off "if (x)" is the better way of
writing it if economy within the JavaScript syntax is your goal. Both are
equally well-formed and so equally valid statements.
But what REALLY annoys me is when someone takes code from the web and
re-uses it after removing the credit to the original author. You can always
tell when this has happened because there is an abrupt shift in programming
style. It's as obvious as when a student takes chunks of text of the
Internet and drops them into an essay.
So, scrappy, untidy code with badly named objects = BAD programmer.
Ripped off code with no credit = BAD and DECEITFUL programmer.
Regards
Ian
Being in a practical business environment, my take on "bad code" is
somewhat different from the flavor of this thread.
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 don't have time to launch into theoretical research as to what is
considered less-than-best-practice by "the experts" (where -expert- is
usually defined as the person himself, and nobody else).
Of more importance than the subtlest of Javascript technicalities
in my line of work is the following. Unmaintainable code is bad code.
Maintainable code is good code. Plain and simple And the definition
of such is simple:
1. if a very tiny program change takes a long time to effect, then
one is dealing with bad code. If every change seems to smoothly fit
in, one is dealing with good code.
2. Say I'm contemplating a program change. If everything I hope
occurs, seems to occur, then this is good, well-written code. If, on
the other hand, every plan I have seems to produce a problem
somewhere, this is bad code.
Such little time is spent on the maintainability issue in business
programming. And upper management doesn't understand where
programming costs are coming from. They are ignorant. If better
workers produced better code, programming costs would plummet 50%.
Douglas Crockford wrote: Code which is confusing is dangerous.
I agree 100%.
I think clarity of code is absolutely essential if the code is to be
distributed, reused, learned from, or modified. For this reason, I would
much rather use conventional coding styles and explicit code blocks rather
than "kewl shortcuts" or other symantics. They might condense the code, and
save a whopping 1k of data transfer, but they make the code much less
useable.
As an example, Richard Cornford's scripts may be technically excellent and
use closures extensively, yet I would challenge even the best javascript
programmers to make sense of it in an effort to learn from or extend it. The
same functionality can be achieved through more typical programming styles
and verbose code.
This is why I get frustrated with Perl programmers, too. Although I like the
language and use it extensively, a habit of many perl programmers it to try
to condense code down to the smallest chunks possible, where functionality
is so jam-packed into small blocks that unrolling it to gain any
understanding is difficult.
Clearly-written code is always better.
--
Matt Kruse http://www.JavascriptToolbox.com
On Wed, 22 Sep 2004 12:22:29 +0000 (UTC), Ian Sedwell
<ia*********@btclick.com> wrote: On 2004/09/20 00:42, in article yc*****************************@40tude.net,
"Andrew Thompson" <Se********@www.invalid> wrote:
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.
The things I look for are well-organised code with meaningful variable and
function names and adequate comments.
but if you're looking on the web, you're not looking at management
code, but release code, these are unlikely to be the same.
But what REALLY annoys me is when someone takes code from the web and
re-uses it after removing the credit to the original author.
how do you know it's from the web, and not from the contractor who
came in to fix up a couple of things?
Jim.
Henrik wrote: Lee wrote:
I said "well-tested", not "seems to work". Fixing code that isn't
broken, simply to pass an automated test, is reckless.
Excuse me, but what is the difference? A script (or program) that is
"well-tested" has presumably executed sucessfully in a (large) set of
more or less artificial states. The larger the set, the better is the
test.
The difference is *huge*. A newbe writes code, tests it in IE, it "seems
to work". An experienced programmer writes code, tests it in as many
browsers/OS as possible. Its "well-tested".
"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
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.
JRS: In article <EG**************@jgharris.demon.co.uk>, dated Tue, 21
Sep 2004 20:54:06, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted : In article <1n*****************************@40tude.net>, Andrew Thompson
<Se********@www.invalid> writesOn 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.
We're not talking about whether the code on the page is arithmetically
reliable, but whether it is worth copying.
A coder who is worth copying will *know* how many seconds there are in a
normal day, at least after the second time that he's read or written it.
Something which is easily to pre-calculate should be calculated at
authoring time, rather than at execution time. Delphi, for example,
enforces that policy as far as it can; write that expression repeatedly,
and a single literal 864e5 will appear in the code AIUI.
What is bad is when 24*60*60*1000 appears more than once in the same js
or html file.
Although it's not easy to invent a shorter, memorable, understandable
and accurate identifier for it. IMHO, both SPD and SecondsPerAverageDay
are worse for code readability.
Moreover, when it does appear, variation in day-length is usually
forgotten,
This thread has greatly ramified. I suggest that, after it has become
relatively inactive, the OP should for clarity start a new thread with
an analogous Subject line, indicating what he then thinks might be a
good consensus view.
--
© 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.
Andrew Thompson wrote: Richard Cornford wrote:
<snip> ..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?
Yes, if your intention is only the showing and hiding (or moving) of CSS
positioned elements (or proprietary LAYER/ILAYER elements) defined in
the HTML and with fixed content then common control logic can be applied
to IE4+, W3C and Netscape 4 browsers, with branching at lower levels for
element reference retrieval, style object normalization and
string/number assignments to dimensions/clipping. So accommodating
Netscape 4 is not that arduous.
Richard.
Dr John Stockton wrote: Richard Cornford wrote: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.
I put the quotes in to suggest that the argument was a string in general
rather than any specific type of literal/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.
Yes, because it takes quite a lot of experience to know when evel really
is the only alternative (or even just objectively the best alternative
in context) then authors who make appropriate use of it are likely to
more experienced (or it might just be a coincidence).
But the main problem with that is that really valid uses are in such a
small minority, and extremely difficult to recognize without the
application of informed judgment, That a quick answer probably could
propose a blanket ban and still be a reasonable criteria .
Suggest eval(...) usually, but not always, bad
Thinking about the subject some more I am coming to the conclusion that
where eval is concerned it might be best to describe examples of its
worst abuses and state them as absolutely indicative of bad code. The
effect would still be to exclude the massive majority of the public code
in which eval appears incorrectly.
So, eval used to resolve a constructed dot notation property accessors
would be a specific example. Along with eval used for sting to number
type conversion, evaling string literals, and evaling values that are
not of string type (such as property accessors that can be expected to
be object references (or null) and numbers). Eliminating code that
features any of that set of specific eval abuses should have a
significant impact on the average quality of any remaining examples.
href="javascript:somefunction()" -wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Has it *no* proper use?
When used for executing side-effect functions it probably has no proper
use as there are plenty of other ways of executing functions in contexts
where the javascript pseudo-protocol could be used. When used to return
page-replacing HTML source code from a string literal, expression or
returned from a function call, then the issues is almost entirely the
javascript dependency introduced (with no potential for
fall-back/degradation).
There certainly has been a valid(ish) use of it when opening new windows
(so requiring that opening new windows be considered valid in the first
place). If the content/HTML source for the new window is to be built
with javascript then assigning it to a global variable in the opening
window and then having the new window read it form there with code such
as:-
win = window.open("javascript:opener.htmlSource;");
- it avoids the timing issues surrounding directly document.write -ing
to the new window that follow from the fact that window opening is
asynchronous.
Of course if Jim is correct about the impact on inter-window/frame
communication of Windows XP SP2 then the use of the javascript
pseudo-protocol in this way would prevent later interaction with the
window opened, though when the point was only to present information to
the user then that wouldn't be important.
In the case of window.open use (and probably also when providing source
for frames/iframes) then the javascript dependency does not follow form
the use of the pseudo-protocol as such, it existed from the point of
assembling the content with javascript and any degradation for browsers
that are not supporting the script could be planned for at an earlier
stage.
That is why I specifically put "appear in HTML" as that is where no
fall-back/degradation can be facilitated. But given that the execution
of a javascript HREF, that does not replace the current page content,
has harmful consequences in many browser environments the best advice
would still be to generally avoid its use (and recognize the very few
cases where it might be a sensible option).
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.
Given that the FAQ states that the default assumption for the group is
that questions asked relate to scripting of web browsers in a public
Internet context it doesn't seem unreasonable for quick answers to also
be written primarily for that context. And while there might be a small
minority of cases where javascript dependency cannot be realistically
avoided in the context of the majority of scripts it certainly can, if
the script is designed for clean degradation from the outset. Making it
clear that clean degradation should be the expectation from a well
designed script doesn't seem unreasonable, at minimum it should make
people aware that the issue exists and encourage them to look at the
consequences.
<snip> 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.
Academic sites (at least the ones associated with universities in the
UK) seem to have considerable interest in accessibility, which is
greatly aided when scripts degrade cleanly. Visitors to sites directly
discussing the execution of javascript might reasonably expect not to be
in a position to see working examples on pages if they visit without
javascript available (except when clean-degradation is also being
demonstrated). Technical sites with other subjects don't have nearly as
good an excuse for javascript dependencies.
(The UK DDA makes no distinction between the type or purpose of a site.
If it is an "information service" or "a facility for entertainment"
(most web sites could reasonably be considered one or the other, if not
both) then the DDA states that it applies. The reality may be that only
commercial and UK government/local authority sites have reason to worry
about the act (in the first case because they are worth suing, and in
the second because the UK government requires it), but personal and
vanity sites are not exempt and the consequences of javascript
dependencies will represent failures to comply (even if there is nobody
enforcing the legislation in the wider context))
Richard.
Matt Kruse wrote: Douglas Crockford wrote:
Code which is confusing is dangerous.
That's true, but 'dangerous' doesn't mean 'bad':-)
As an example, Richard Cornford's scripts may be technically excellent and
use closures extensively, yet I would challenge even the best javascript
programmers to make sense of it in an effort to learn from or extend it.
So far Mr Cornford doesn't write scripts for people to understand them
(although he does provide verbose comments and clear interfaces to his
components) but to experiment javascript patterns. Javascript, crossing
a full object-orientation with the functional paradigm, presents quite a
particularity[1], and it's too bad no-one (or so few) haven't tried to
study the essence of the language, see how the javascript paradigm could
be developed and applied. That's in this perspective, IMHO, that Mr
Cornford's writing should be read and learnt from.
Regards,
Yep.
---
[1] I've recently heard about Pizza and Nice - it's particularly
interesting to find out how functional programming can be layered upon Java.
Randy Webb skrev: Henrik wrote:
Lee wrote:
I said "well-tested", not "seems to work". Fixing code that isn't
broken, simply to pass an automated test, is reckless.
Excuse me, but what is the difference? A script (or program) that
is "well-tested" has presumably executed sucessfully in a (large)
set of more or less artificial states. The larger the set, the
better is the test.
The difference is huge. A newbe writes code, tests it in IE, it
"seems to work". An experienced programmer writes code, tests it in
as many browsers/OS as possible. Its "well-tested".
"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
--
Henrik
On Wed, 22 Sep 2004 13:42:23 +0100, Dr John Stockton wrote: This thread has greatly ramified.
Indeed.
..I suggest that, after it has become
relatively inactive, the OP should for clarity start a new thread with
an analogous Subject line, indicating what he then thinks might be a
good consensus view.
That is what I am thinking as well.
A 'quick summary' of my impressions thus far though.
Ultimately, this is about poorly written JS, as
opposed carefully crafted, *robust* code that
does bad things.
If we go telling people not to use good code that
does bad things, it dilutes the message of not
copying poor code.
As such, I am veering away from recommending blanket
condemnation of many of the applications of JS that
might lead to useability problems.
There have also been interesting arguments either way
as to whether 'good code' is well documented and easy
to maintain, or whether the author in fact intended it
as the ultimate stand-alone 'black box' type code.
Obviously the well documented code is a far better
teaching tool, but some learners can still pick-up
useful techiques from prying apart the 'black-box'
code. As far as the function of the JS itself goes,
whether it is terse or verbose seems irrelevant. As
each type has it's own place, I do not think we can
make any blanket recommendations on that either.
Ultimately I am tending toward a very short list
of extremely obvious errors. I do not know if that
will be of enough use to justify inclusion in the
FAQ.
...leaving this thread, temporarily, on that thought.
[ Thanks to all contributors so far, and please
keep the ideas coming. ]
--
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
Henrik wrote: Randy Webb skrev:
<--snip--> "seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
No, I didn't agree with your point. I was pointing out the wording. In
now way, shape, form or fashion do I agree that "seems to work" code is
"well-tested" code because they are not even close to being the same thing.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Henrik said:
Randy Webb skrev:
Henrik wrote:
> Lee wrote:
>
> > I said "well-tested", not "seems to work". Fixing code that isn't
> > broken, simply to pass an automated test, is reckless.
> >
>
>
> Excuse me, but what is the difference? A script (or program) that
> is "well-tested" has presumably executed sucessfully in a (large)
> set of more or less artificial states. The larger the set, the
> better is the test.
The difference is huge. A newbe writes code, tests it in IE, it
"seems to work". An experienced programmer writes code, tests it in
as many browsers/OS as possible. Its "well-tested".
> "seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
So, to you, "lousy software" and "good software" mean the same thing,
because both are very loose descriptions of an unspecified degree of
quality?
> Randy Webb <Hi************@aol.com> wrote:
The difference is *huge*. A newbe writes code, tests it in IE, it "seems
to work". An experienced programmer writes code, tests it in as many
browsers/OS as possible. Its "well-tested".
"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
Somewhere in the last few post, people seemed to have lost their way on
the subject of testing. More testing is generally better then less.
For the novices who are the ones who will likely be copying code, we
need to tell them there is more to the internet than IE.
I do not think one can do a complete test on the javascript code. How
many people test on all one hundred browsers anyway. You pick a
representative sample.
Some Javascript sites include a working example of the code. For these
sites, suggest that the viewer try a non-IE browsers.
I believe a good addition would be to test on several browsers.
Just testing in Firefox and IE will be a big help.
This brings up these ideas:
1) Check for IE features and IE access to variables. We come across
them daily in this forum.
2) Copyright date if present. If the date is a few years old the code
will be less likely to work.
Robert
Matt Kruse wrote: Douglas Crockford wrote: Code which is confusing is dangerous.
I agree 100%.
I think clarity of code is absolutely essential if the code
is to be distributed, reused, learned from, or modified.
Four very disparate requirements that are unlikely to simultaneously
apply to any one piece of code. The first two of which are unrelated to
the clarity of source code and more dependent on the quality of
accompanying documentation.
For this reason, I would much rather use conventional
coding styles and explicit code blocks rather than "kewl
shortcuts" or other symantics.
It is not like you have the choice.
They might condense the code, and save a whopping
1k of data transfer,
You just love citing those baseless numbers don't you?
but they make the code much less useable.
And you have very vague concept of 'use'.
From the point of view of someone sitting in front of a web browser,
'usable' applies to the GUI and so long as it is useable the code behind
the scenes in of no more than academic interest.
From the point of view of someone wanting to use code written by someone
else the simplicity of the interface, and the quality of its
documentation are key to their ability to use it easily. So long as its
external behaviour is as advertised the internal details are not
important.
Are there any other individuals who can be expected to have an attitude
about "usable" in relation to javascript code? Well, maybe individuals
who want to lift an algorithm that they are incapable of writing for
themselves. Not being able to understand source code can certainly be a
barrier to that use of javascript.
As an example, Richard Cornford's scripts may be technically
excellent and use closures extensively, yet I would challenge
even the best javascript programmers to make sense of it in
an effort to learn from or extend it.
You underestimate the best javascript programmers, though they may not
have anything to learn from it, or see any purpose in attempting to
extend it.
The same functionality can be achieved through
more typical programming styles and verbose code.
What would be a typical programming style? On the Internet that would be
the ropy and horrendously inefficiently implemented procedural style.
Assuming exactly the same functionality was implemented in that style
the results would be less 'usable' than anything I have published.
But of course you mean *your* programming style. Well you will find that
to the typical author of javascript for web pages your style is as
incomprehensible to them as mine is to you. There may be a larger
minority of javascript authors who have progressed past the point of
comprehending your style than have passed the point of understanding
mine but it is still a small minority. So what are your after here; that
people should learn javascript up to your level and then stop? Why
should they, just so you feel better about never bothering to learn how
to do anything any better?
<snip> Clearly-written code is always better.
Code that is confusing can be clearly written (and well commented).
Personally I am confused as to why your code features functions that are
clearly analogous to 'static' in class-based languages assigned as
methods of object instances. It is very clear that that is happening,
but there doesn't appear to be any clear reason for it to be happening.
Richard.
> if(isPosInt(document.forms[0].total(i).value)){
I'll quote from Mike Winter
" Don't use parentheses for subscripting. Not only is it wrong, but only
IE will accept it."
I think this would be a good addition for things to look out for.
I know it could be IE only section & validate. But what is the change
of change variable reference styles in on script anyway.
Robert
Richard Cornford wrote: Matt Kruse wrote: I think clarity of code is absolutely essential if the code
is to be distributed, reused, learned from, or modified. Four very disparate requirements that are unlikely to simultaneously
apply to any one piece of code.
I disagree, of course. I think most code posted on web sites for others to
use have those 4 things in mind.
They might condense the code, and save a whopping
1k of data transfer,
You just love citing those baseless numbers don't you?
Yes. Yes I do. They're called approximations based on experience with
tweaking scripts.
but they make the code much less useable.
And you have very vague concept of 'use'.
In the context of this thread, I think the concept of 'usable' is pretty
clear. We're talking about evaluating code and deciding whether it is a good
choice to be used, modified, etc. So in this context, usable probably means
usable to the person who is going to be using, modifying, etc the code.
Well you will find
that to the typical author of javascript for web pages your style is
as incomprehensible to them as mine is to you.
Well, I disagree. I try to write code in such a way that anyone familiar
with similar languages will be able to recognize the same constructs,
patterns, and style that they are used to seeing in their other work.
So what are your after here;
that people should learn javascript up to your level and then stop?
No, it has nothing to do with how much javascript a person chooses to learn.
The discussion is about evaluating code which is made available for others
to use. The topic of this sub-thread is how clear and easily-understandable
code is better for such purposes than complicated, "kewl" code that
accomplishes the same task.
My point was, some people put up example code that may be technically
excellent, but probably isn't as good of a choice for a person who want to
use, learn from, and modify an existing solution. Your code was my example.
Why should they, just so you feel better about never bothering to
learn how to do anything any better?
"better" is subjective.
If the same task is accomplished using closures and your style, or some
'procedural' style, who does one evaluate which one is 'better'? As I see
it, that depends on the goal. And in the context of this discussion, the
goal is to find the best code to use, learn from, and modify.
Personally I am confused as to why your code features functions that
are clearly analogous to 'static' in class-based languages assigned as
methods of object instances.
If you provide an example, I'll tell you why I did what I did. *shrugs*
--
Matt Kruse http://www.JavascriptToolbox.com
Lee skrev:
So, to you, "lousy software" and "good software" mean the same thing,
because both are very loose descriptions of an unspecified degree of
quality?
No, of course not. But one man's "well-tested" program may be
somerthing another calls "seems to work". Just as one man's "lousy
program" may be called "good software" by another. As long as we don't
define our phrases we can use them as we please.
--
Henrik
Randy Webb skrev: Henrik wrote:
Randy Webb skrev:
<--snip-->
> "seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not
a blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
No, I didn't agree with your point. I was pointing out the wording.
In now way, shape, form or fashion do I agree that "seems to work"
code is "well-tested" code because they are not even close to being
the same thing.
Then I wonder what you mean by '"well-tested" may be a subset of "seems
to work"'. I have probably misunderstood that period.
--
Henrik
On Thu, 23 Sep 2004 04:08:01 GMT, Robert wrote: " Don't use parentheses for subscripting. Not only is it wrong, but only
IE will accept it."
I think this would be a good addition for things to look out for.
Thanks for the tip Robert..
I know it could be IE only section & validate. But what is the change
of change variable reference styles in on script anyway.
...could you clarify that last sentence for me?
[ I'm pretty sure it contained something I don't want
to miss, but I cannot make head nor tail of it! ;-) ]
--
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
On Thu, 23 Sep 2004 04:08:01 GMT, Robert <rc*******@my-deja.com> wrote: if(isPosInt(document.forms[0].total(i).value)){
I'll quote from Mike Winter
" Don't use parentheses for subscripting. Not only is it wrong, but only
IE will accept it."
Though I don't like how I phrased that. The fact that it's wrong is the
main point. Perhaps something more direct, like:
"It's incorrect (though IE will accept it)."
Does IE's support for it even need to be mentioned? For an explanation as
to why the syntax appears, I suppose it does.
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Henrik said:
Lee skrev:
So, to you, "lousy software" and "good software" mean the same thing,
because both are very loose descriptions of an unspecified degree of
quality?
No, of course not. But one man's "well-tested" program may be
somerthing another calls "seems to work". Just as one man's "lousy
program" may be called "good software" by another. As long as we don't
define our phrases we can use them as we please.
But you just claimed that "well-tested" meant the same thing as
"seems to work". Are you saying that you now recognizes that,
although not exactly quantified, they are significantly different,
just like "lousy" and "good"?
On 2004/09/22 22:38, in article ci*********@drn.newsguy.com, "Lee"
<RE**************@cox.net> wrote: Henrik said:
Randy Webb skrev:
Henrik wrote:
Lee wrote:
> I said "well-tested", not "seems to work". Fixing code that isn't
> broken, simply to pass an automated test, is reckless.
>
Excuse me, but what is the difference? A script (or program) that
is "well-tested" has presumably executed sucessfully in a (large)
set of more or less artificial states. The larger the set, the
better is the test.
The difference is huge. A newbe writes code, tests it in IE, it
"seems to work". An experienced programmer writes code, tests it in
as many browsers/OS as possible. Its "well-tested".
"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
So, to you, "lousy software" and "good software" mean the same thing,
because both are very loose descriptions of an unspecified degree of
quality?
So there's a lot to be said for functional program languages, after all.
Lets hear it for good old LISP!
On 2004/09/22 22:48, in article M8********************@comcast.com, "Randy
Webb" <Hi************@aol.com> wrote: Henrik wrote:
Randy Webb skrev:
<--snip-->
"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not a
blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
No, I didn't agree with your point. I was pointing out the wording. In
now way, shape, form or fashion do I agree that "seems to work" code is
"well-tested" code because they are not even close to being the same thing.
Randy is correct. They are far from being the same thing.
Henrik wrote: Randy Webb skrev:
Henrik wrote:
Randy Webb skrev:
<--snip-->
>"seems to work" seems to cover this nicely.
No, "well-tested" may be a subset of "seems to work" but it's not
a blanket coverage.
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
No, I didn't agree with your point. I was pointing out the wording.
In now way, shape, form or fashion do I agree that "seems to work"
code is "well-tested" code because they are not even close to being
the same thing.
Then I wonder what you mean by '"well-tested" may be a subset of "seems
to work"'. I have probably misunderstood that period.
Using Numbers as a comparison. 1 is a Number. -1 is a Number. 1 is a
Positive Integer, -1 is not a Positive Integer. Positive Integers are a
sub-set of Numbers, but because something is a Number doesn't make it a
Positive Integer.
Direct comparison in javascript :
Script 1:
document.all.imageName.src="someOtherImage.jpg";
Tested in IE, it "seems to work".
Script 2:
document.images['imageName'].src="someOtherImage.jpg";
Tested in IE, it "seems to work".
The second script is "well-tested" though, because its known to work in
almost every browser that supports images. I don't know of a browser
that supports document.images that the second doesn't work in. I only
know of 4 browsers (out of 150 or so that I know of) where the first one
will work.
Both "seem to work", but on the second one is "well-tested".
Makes the well-tested a subset of "seems to work".
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
In article <9n***************************@40tude.net>,
Andrew Thompson <Se********@www.invalid> wrote: " Don't use parentheses for subscripting. Not only is it wrong, but only
IE will accept it." I know it could be IE only section & validate. But what is the change
of change variable reference styles in on script anyway.
..could you clarify that last sentence for me?
[ I'm pretty sure it contained something I don't want
to miss, but I cannot make head nor tail of it! ;-) ]
I isn't all that profound & I wrote it rather late.
I was saying there is the minor chance that the Javascript code could
work on the Internet because it could be in an IE only section of the
code. That is when the same Javascript code runs on Netscape it would
work because in the Netsape case the author would avoid this code.
Then I tried to comment that it would probably be in a section of code
where the author did an explicit check for IE and doing checks for IE
isn't recommended anyway.
Then I thought that what author would change styles of coding to use IE
style selection in the IE only code and W3C style in other sections of
code? So just spotting code like this marks the script not ready for
the Internet.
I think this style of coding is confusing anyway and should not be used:
document.forms[0].total(i).value
Thanks for you interest in avoiding statements like this.
Robert
Andrew Thompson <Se********@www.invalid> wrote in message news:<16*****************************@40tude.net>. .. On Mon, 20 Sep 2004 12:57:28 GMT, Andrew Urquhart wrote:
http://www.developer-x.com/content/innerhtml/
Thanks Andrew, I've bookmarked that and will have a
close look over it when I get the chance.
Very helpful link.
JRS: In article <rc*****************************@news2.west.earthl ink.n
et>, dated Thu, 23 Sep 2004 02:35:49, seen in news:comp.lang.javascript,
Robert <rc*******@my-deja.com> posted :
2) Copyright date if present. If the date is a few years old the code
will be less likely to work.
If the date is seemingly current, check that it has not been obtained
from new Date().
--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
In MS OE, choose Tools, Options, Send; select Plain Text for News and E-mail.
JRS: In article <ci*******************@news.demon.co.uk>, dated Wed, 22
Sep 2004 18:30:27, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted : Dr John Stockton wrote: Suggest eval(...) usually, but not always, bad
Thinking about the subject some more I am coming to the conclusion that
where eval is concerned it might be best to describe examples of its
worst abuses and state them as absolutely indicative of bad code. The
effect would still be to exclude the massive majority of the public code
in which eval appears incorrectly.
So, eval used to resolve a constructed dot notation property accessors
would be a specific example. Along with eval used for sting to number
type conversion, evaling string literals, and evaling values that are
not of string type (such as property accessors that can be expected to
be object references (or null) and numbers). Eliminating code that
features any of that set of specific eval abuses should have a
significant impact on the average quality of any remaining examples.
Agreed. Include those who believe that an assignment of an expression
to a variable must be done as in X = eval(Y+Z) though their code
will probably fail enough other tests too ... 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.
Given that the FAQ states that the default assumption for the group is
that questions asked relate to scripting of web browsers in a public
Internet context it doesn't seem unreasonable for quick answers to also
be written primarily for that context. And while there might be a small
minority of cases where javascript dependency cannot be realistically
avoided in the context of the majority of scripts it certainly can, if
the script is designed for clean degradation from the outset. Making it
clear that clean degradation should be the expectation from a well
designed script doesn't seem unreasonable, at minimum it should make
people aware that the issue exists and encourage them to look at the
consequences.
One need only add "unless scripting is fundamental"; consider, for
example, <URL:http://www.merlyn.demon.co.uk/astro.htm#Calc> as if it
were a complete page. Without script, it serves only to show what it
cannot do.
On == true - ISTM that, while it is perfectly legal and reliable,
and wastes only a few characters (unlike, say, parenthesis-indexing is
eval-indexing) it is a /bad sign/ : a coder who feels it necessary is a
coder whose other code should be treated with suspicion.
It is well-known that certain page-editing tools generate bad and/or
bloated HTML. If there are javascript-generating tools, stand-alone or
included in page-editing ones, which give similarly bad code, then it
would be worth warning against copying their output /verbatim/. How one
tells, I do not know.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
some Astro stuff via astro.htm, gravity0.htm; quotes.htm; pascal.htm; &c, &c.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:
[snip] One need only add "unless scripting is fundamental"; consider, for
example, <URL:http://www.merlyn.demon.co.uk/astro.htm#Calc> as if it
were a complete page. Without script, it serves only to show what it
cannot do.
It must be said that the majority of things I can remember seeing your
pages *do* [1] does not require scripting. You could perform the various
calculations server-side and resend the page with the results. It doesn't
require Javascript, though client-side scripting would be quicker with
less network traffic.
That said, your Javascript pages serve to demonstrate scripts. It would be
senseless to expect them to operate without scripting enabled.
[snip]
Mike
[1] Notable exceptions are tests like the approximate resolution of
setTimeout and the behaviour of the Date object when affected by Daylight
Savings. I'm sure there are others.
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Michael Winter wrote: Robert wrote:
<snip> ... . The fact that it's wrong is
the main point. Perhaps something more direct, like:
"It's incorrect (though IE will accept it)."
<snip>
Strictly, numerous browsers will support it. If you - typeof - test the
various collections in Opera, Konqueror/Safari or IceBrowser you will
find that the result is 'function'. They can be called and the
parenthesised notation that represents a function call will work with
them.
The reason for preferring the bracket notation is that it works reliably
on every browser that will allow parenthesised access, plus all the
browsers that do not. And on any occasion where one formulation fits all
(collection feature supporting) browsers, cross-browser scripting is
simplified by using that formulation exclusively.
Richard.
Matt Kruse wrote: Richard Cornford wrote: Matt Kruse wrote: I think clarity of code is absolutely essential if
the code is to be distributed, reused, learned from,
or modified.
Four very disparate requirements that are unlikely to
simultaneously apply to any one piece of code.
I disagree, of course. I think most code posted on web
sites for others to use have those 4 things in mind.
The majority of code posted to web sites with the apparent intention
that others would use it is so appallingly bad that it is difficult to
see how it could have been created with any design concept let alone
attempting to satisfy 4 simultaneously.
However, I write code with the intention that it be learnt from, and to
facilitate that I formally structure it, heavily comment it and then
comment upon it (see the FAQ notes). I also write code to be re-used,
for which formal structure, adequate comments and suitable documentation
best satisfy that requirement. And I prepare code for distribution, at
which point it loses much of its structure, most of its comments and
probably its meaningful internal identifiers. Even if the javascript is
equivalent (originally identical) in all three cases the observable form
of the results is (and should be) distinct. Trying to wrap all three
requirements up in the same piece of source code is most likely to
produce results ill suited to any of them.
They might condense the code, and save a whopping
1k of data transfer,
You just love citing those baseless numbers don't you?
Yes. Yes I do. They're called approximations based on
experience with tweaking scripts.
My code addresses issues that you dismiss as insignificant and so have
never implemented, and you don't understand the techniques I use so you
are in no position to judge the consequences of there application
(beyond dismissing them because your lack of understanding produces a
perception of complexity). This makes me think you have no experience
that you can apply as a basis for approximation.
but they make the code much less useable.
And you have very vague concept of 'use'.
In the context of this thread,
That being the thread with the subject "Top warning signs of bad code?".
I think the concept of 'usable' is pretty clear.
I don't see why it should be as you are the only person to have raised
the subject in this context and when you talk of 'users' it is usually
unclear who you intend the subject to be.
We're talking about evaluating code and deciding
whether it is a good choice to be used, modified, etc.
No we are not. The subject of this thread is identifying, and excluding,
bad code through the application of formal rules (of some sort or
another). What happens to the code that is not excluded by the (any)
resulting rules has not been laid down. Nor is it a reasonable
expectation that any set of formal rules would be able to eliminate all
bad code, so the residue certainly could not be categorised as 'good
code', or actually be considered suited to any purpose.
So in this context,
Yes?
usable probably means usable to the person who is
going to be using, modifying, etc the code.
"usable to the person who is going to be using ...", but using for
what? As an example to be learnt from, as a cut-and-paste drop in, as a
starting point for some unspecified elaboration? If it is just a
question of deploying a script on a web site the script best suited to
that use would be a black-box with a simple interface (and probably
pre-minimised source) that did the required job for the least effort on
the part of the individual deploying it.
Anyone wishing to use a third party's script as the starting point for
some other script is going to need to fully understand that script, so
they will appreciate adequate comments, formal structure, and a script
authoring style that is within there comprehension (so dependent on the
knowledge of the individual).
And those interested in learning will have different uses for different
scripts depending on where they are starting form. The novice will have
no use for a script that demonstrates advanced techniques, and an
intermediate to advanced student won't learn much from a script that was
useful to a novice.
Well you will find that to the typical author of
javascript for web pages your style is
as incomprehensible to them as mine is to you.
Well, I disagree.
Then maybe you should spend more time looking at the javascript behind
web sites because it is very clear that the majority of it came into
existence without any involvement on the part of a programmer. Their
creators mostly wouldn't comprehend your object implementations.
I try to write code in such a way that anyone familiar
with similar languages will be able to recognize the same
constructs, patterns, and style that they are used to
seeing in their other work.
Similar languages? You write code so that it can be understood by the
authors of Scheme and Self? Why?
But in reality you mean that you write scripts so that they are familiar
to the authors of the very dissimilar language Java. It isn't actually a
good idea to write javascript that apes Java because you will be
crippling your scripts and achieve no more to than give the programmers
of Java reinforcement for their prejudice that javascript is inferior,
as you demonstrate it not really delivering what Java is good at. There
is more to Java than the pattern of the objects used, there is the whole
object oriented ethos. When javascript apes Java it cannot deliver more
than a shadow of OO, and the Java programmers can recognise that. But
javascript can implement anything so OO design methodologies can be
fully applied javascript authoring, though it is javascript that needs
to be understood in order to achieve that, not Java.
<snip> The discussion is about evaluating code which is made
available for others to use. The topic of this sub-thread
is how clear and easily-understandable code is better for
such purposes than complicated, "kewl" code that
accomplishes the same task.
Do you really believe that I perceive my code as complex; that I am
masochistic enough to choose the complex over the simple? Do you think
that I have spent my time studying javascript, experimenting with its
application and debating the results on this group out of a desire to
achieve the "kewl"? The reality is that in cross-browser scripting there
are a mass of issues that should be handled, and I am looking for better
ways of handling them. If, as a result of my efforts, I modify the style
I use in implementing scripts then that is the result of informed
judgement and is motivated by a recognition that doing so delivers
tangible benefits.
Those benefits may come form performance improvements, better
encapsulation, fuller application of OO principles, increased code
re-use, improved reliability, etc, but above all the most tangible
benefit is apparent in the time it takes to create new scripts. for
example, that table scrolling script took 6 hours to design, implement,
test and upload (yes I did time the whole process). That is hardly a
symptom of real complexity in the implementation.
You think you can implement equivalent functionality in your preferred
style, so could I, but I choose not to because I know what result would
be, and how it would perform.
My point was, some people put up example code that may
be technically excellent, but probably isn't as good of
a choice for a person who want to use, learn from, and
modify an existing solution. Your code was my example.
If people want to learn how to exploit closures they are not going to do
so from your code. They would be better off reading the examples that I
created for that specific purpose, along with its accompanying
explanation. If they have less ambitious interests then there is plenty
of other code in the FAQ to learn form.
Why should they, just so you feel better about never
bothering to learn how to do anything any better?
"better" is subjective.
Better is a relative term and many criteria can be applied to make
objective judgements of it.
<snip> And in the context of this discussion, the goal is to
find the best code to use, learn from, and modify.
Again, no. The subject of this thread is the identification and
rejection of *bad* code, without any regard for the purpose of that
code.
Personally I am confused as to why your code features
functions that are clearly analogous to 'static' in
class-based languages assigned as methods of object instances.
If you provide an example, I'll tell you why
I did what I did.
The first example that comes to hand is be your - DynamicOptionList -
object, the constructor of which assigns the globally declared
functions - DOL_populateChild -, - DOL_findMatchingOptionInArray - and -
DOL_addNewOptionToList - to the - populateChild -, -
findMatchingOptionInArray - and - addNewOptionToList - properties of the
objects it is constructing. Making them all instance methods, although
none of the functions makes reference to the object instance to which it
is attached, instead acting only on their arguments, even though they
are called as method of the instance.
As the action of those functions relates to the 'class' rather than the
object instance they should be static (and they would have been in
Java), and probably private or protected static at that.
*shrugs*
You may not care, but it is you who are claming that your code
implements constructs and patterns that can be recognised by Java
programmers. An OO programmer will recognise the distinction between a
static method and an instance method.
Richard.
On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton wrote: ..If there are javascript-generating tools, stand-alone or
included in page-editing ones, which give similarly bad code, then it
would be worth warning against copying their output /verbatim/.
I have never used tools to generate script.
What are the main contenders? And what sorts of specific
things do they do that might warn against their code?
I would consider browser-sniffing a definite warning,
while merely producing bloated script (possibly due
to bloated mark-up) would be much less so..
How one tells, I do not know.
...nor I, are there any tell-tale signs of the tools in question?
AFAIR one tool seems to prefix everything with MM_ or
similar*, though I cannot immediately recall which.
* I'm here to learn, and code like that hurts my head, so given
there are so many examples of qn.s discussed in this group that
do *not* involve such code, I examine those examples instead. ;-)
--
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
On Thu, 23 Sep 2004 17:13:26 GMT, Robert wrote: [ I'm pretty sure it contained something I don't want
to miss, but I cannot make head nor tail of it! ;-) ]
I isn't all that profound & I wrote it rather late.
LOL ..know the feeling!
(big snip) Thanks for you interest in avoiding statements like this.
Thank you for clarifying ( and yes, it was something I wanted to know :-).
--
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
On Fri, 24 Sep 2004 01:39:38 +0100, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote: Michael Winter wrote: Robert wrote:
<snip> ... . The fact that it's wrong is
the main point. Perhaps something more direct, like:
"It's incorrect (though IE will accept it)."
<snip>
Strictly, numerous browsers will support it. If you - typeof - test
the various collections in Opera, Konqueror/Safari or IceBrowser you
will find that the result is 'function'. They can be called and the
parenthesised notation that represents a function call will work with
them.
Hmm, so it does.
I must say I'm confused (so excuse the befuddled thought process that
follows). Why exactly is this syntax supported?
As far as I can see, it's only used for collections. Even IE insists that
arrays are subscripted with square brackets. Collections in the DOM can be
subscripted, but it explicitly states the use of square brackets.
Is it then just a coping measure for IE's collections? Even so, that then
raises the question for why Microsoft[1] decided to allow parentheses for
something that is so much like an array.
[snip]
Mike
[1] I assume it was Microsoft's idea, as Mozilla doesn't allow
parentheses. If it was Netscape's, I'd assume that Mozilla would follow
suit. Unless they decided to "purify" the syntax.
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Lee skrev: But you just claimed that "well-tested" meant the same thing as
"seems to work". Are you saying that you now recognizes that,
although not exactly quantified, they are significantly different,
just like "lousy" and "good"?
No, no. But I (hoped to) claim that they both are vague expressions
that are used to mean whatever the writer need to express. We need a
way to quantify such expressions.
--
Henrik
Randy Webb skrev: Henrik wrote:
Then I wonder what you mean by '"well-tested" may be a subset of
"seems to work"'. I have probably misunderstood that period.
[snip]
Makes the well-tested a subset of "seems to work".
Sorry. I read your statement as the effort of making a program
"well-tested" was a subset of the effort of making it "seem to work".
My mistake.
I return to the subject ...
--
Henrik
Randy Webb wrote: Henrik wrote:
You use many words to agree my point. Whether "well-tested" is a
subset (or a superset) of "seems to work" is not relevant; both are
very loose descriptions of an unspecified amount of experiments.
No, I didn't agree with your point. I was pointing out the wording. In
now way, shape, form or fashion do I agree that "seems to work" code is
"well-tested" code because they are not even close to being the same thing.
Much as I hate to join in here, but the argument seems to be going round
in circles and getting nowhere so can I just point out that a rather
clever chappie called Alan Turing pointed out that there are only two
states you can *prove* about a computer program: stops or doesn't stop
(and even that you can only prove by running it - possibly forever).
In short, "seems to work" and "works" are much the same and all your
arguments are about when it stops "seeming" or stops "working".
Mark Preston <us****@nosource.co.uk> writes: Much as I hate to join in here, but the argument seems to be going
round in circles and getting nowhere so can I just point out that a
rather clever chappie called Alan Turing pointed out that there are
only two states you can *prove* about a computer program: stops or
doesn't stop (and even that you can only prove by running it -
possibly forever).
With that definiton of "prove", then you can prove any other property
too, possibly by waiting for it forever. (It should be noted that
Turing's programs couldn't do output :).
I much prefer to say that there is only property you can prove about
the execution of programs in a general way: true (which is trivial).
However, whether or not we can say something about the exeuction of a
program, doesn't necessarily affect what we can say about the program
itself. We can say that a program uses only features defined by the
W3C DOM specification.
/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.'
In article <oc**************@merlyn.demon.co.uk>, Dr John Stockton
<sp**@merlyn.demon.co.uk> writes
<snip> We're not talking about whether the code on the page is arithmetically
reliable, but whether it is worth copying.
When you aren't sure that the code is arithmetically reliable you can't
possibly say that it's worth your copying it.
A coder who is worth copying will *know* how many seconds there are in a
normal day, at least after the second time that he's read or written it.
If you are sure you have remembered the number correctly, and you are
sure you would notice a typing error, and no-one else will be
maintaining the code, and no-one else will be copying the code, then you
can write 864e5 with a clear conscience.
If not then you can't.
Something which is easily to pre-calculate should be calculated at
authoring time, rather than at execution time.
<snip>
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.
John
--
John Harris
Michael Winter wrote: Richard Cornford wrote:
<snip> Strictly, numerous browsers will support it. If you - typeof -
test the various collections in Opera, Konqueror/Safari or
IceBrowser you will find that the result is 'function'. They
can be called and the parenthesised notation that represents
a function call will work with them.
Hmm, so it does.
I must say I'm confused (so excuse the befuddled thought
process that follows). Why exactly is this syntax supported?
I suppose that with the Internet full of IE only code when it is not
that difficult for a browser manufacturer to do their implementation in
a way that will tolerate some Microsoftism, and so avoid there browser
looking broken to the users, then they may as well do so. After all, in
javascript a function is an object so a collection can be implemented as
a function instead of just an object without too much effort (though it
does make some caution necessary with typeof testing of objects. It has
go to be less effort to facilitate this than it is to implement the
mechanism behind the document.all collection, and even Mozilla have made
that concession to IE (albeit invisibly).
As far as I can see, it's only used for collections.
Even IE insists that arrays are subscripted with
square brackets. Collections in the DOM can be
subscripted, but it explicitly states the use of
square brackets.
Yes, there is absolutely no need to be using parentheses around
collection indexes instead of brackets. And the standards go with
brackets only.
Is it then just a coping measure for IE's collections?
I think so.
Even so, that then raises the question for why
Microsoft[1] decided to allow parentheses for
something that is so much like an array.
<snip>
There might be some sort of historical precedence form another language
commonly used at Microsoft that suggested it, or it could be an
implementation detail that allowed it and when someone noticed it caught
on. But it is as likely as not an effort to allow browser script authors
to get away with being undisciplined, even to the extent of not grasping
the distinction between property access and function calls.
Richard.
JRS: In article <opsesrbjy0x13kvk@atlantis>, dated Thu, 23 Sep 2004
20:30:03, seen in news:comp.lang.javascript, Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted : On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:
[snip]
One need only add "unless scripting is fundamental"; consider, for
example, <URL:http://www.merlyn.demon.co.uk/astro.htm#Calc> as if it
were a complete page. Without script, it serves only to show what it
cannot do.
It must be said that the majority of things I can remember seeing your
pages *do* [1] does not require scripting. You could perform the various
calculations server-side and resend the page with the results.
Not so. My Web site host does not offer server-side processing. That's
probably why I write nothing about the topic.
Moreover, client-side processing has distinct advantages. It uses
client-side resources, which are free of cost to me and to my host
(returning a page adds to the bandwidth-used count). And it continues
to work for a dial-up user even when he has broken the connection.
BTW, bandwidth-usage limitation means that my pages may show a variation
in fetch-ability during each 24 weekday hours, although caching at your
ISP may partly conceal that. One might try looking at my <URL: http://ww
w.merlyn.demon.co.uk/gullible.htm>, a small and presumably unpopular
page - but only after the caches used by all those who see the above
link have had time to flush! - or use gullible.htm?<getTime> .
--
© 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.
On Fri, 24 Sep 2004 14:12:16 +0100, Dr John Stockton wrote: ..client-side processing has distinct advantages. It uses
client-side resources, which are free of cost to me and to my host
(returning a page adds to the bandwidth-used count). And it continues
to work for a dial-up user even when he has broken the connection.
Don't forget speed of response to the end user.
The script may take a little time to download initially,
but once it is loaded, the UA can avoid the time needed
for a round trip to the server for page updates.
[ I find it painful to fill in complex forms that
lack client side validation! ]
--
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
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*.
I, however, know that 70 yards square is about an acre, and that it is a
"sensible" fraction of a square mile. From that, the 4840 appears in
the process of deciding just what an acre is.
And, if I prefer not to think about it, I keep a small dictionary (LOD)
well within reach, and that gives 4840 directly, in the "acre" entry,
without citing chains or furlongs (the adjacent Webster, of similar
size, just says "a measure of land").
So the use of the single-number form does not show that the author has
chosen to do the multiplication himself.
There is another reason for preferring compact forms.
In a set of Web pages, written at different times, you might diversely
have remembered one acre as 1 c * 1 f or as 1 f * 1 c, and might have
remembered 1 f as 1 c * 10 or as 10 * 1 c - so you could have used all
three of 10*22*22, 22*10*22, 22*22*10. All are OK, but if you should
want to locate all acre-conversions by searching the source files, e.g.
with MiniTrue, you have to search for all three combinations; I only
have to search for 4840.
For 864e5, 24*60*60*1000 or 1000*60*60*24 might be used, and the factors
might appear elsewhere, but 864e5 is unlikely to be wanted in another
context. In fact, if that number were needed in another context, I'd
personally use 86400000 or 8.64e7, just to show that it was not the
accustomed 864e5.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> Update hope?
JRS: In article <cj*******************@news.demon.co.uk>, dated Fri, 24
Sep 2004 16:40:29, seen in news:comp.lang.javascript, Mark Preston
<us****@nosource.co.uk> posted : Much as I hate to join in here, but the argument seems to be going round
in circles and getting nowhere so can I just point out that a rather
clever chappie called Alan Turing pointed out that there are only two
states you can *prove* about a computer program: stops or doesn't stop
(and even that you can only prove by running it - possibly forever).
He showed, IIRC, that the general halting problem is insoluble, which
means that there are programs for which there is no way of telling
whether they will ever stop is to run them and observe that they have
stopped.
A program of finite length and without loops will clearly stop in a
finite time.
The javascript program skeleton x = ? ; while (x) y = -y ; will
terminate either rapidly or never, depending on what ? is replaced by;
and for any given ? one can reliably predict which is the case.
Some programs can be proven to be correct; in javascript, the negation
function function neg(x) { return -x } is, in a correct
implementation, infallible and always completes.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:
[Turing] He showed, IIRC, that the general halting problem is insoluble, which
means that there are programs for which there is no way of telling
whether they will ever stop is to run them and observe that they have
stopped.
Almost (I'll go off on that tangent at the end :)
A program of finite length and without loops will clearly stop in a
finite time.
True, however it's not trivial to deduce that there are no loops
if the language has first class functions. :)
Behold:
---
function fix(F) {
function w(f) { return f(f); }
function wf(f) { return function(x){ return F(f(f))(x); } }
return w(wf);
}
function recDepth(depth) {
return function(a) {
if (a instanceof Array && a.length > 0) {
return 1 + depth(a[0]);
} else {
return 0;
}
}
}
var depth = fix(recDepth);
alert(depth([[[[42]]]]));
// alerts 4
var recArr = [];
recArr[0] = recArr;
alert(depth(recArr));
// diverges - you might have to kill the browser :)
---
This code contains:
- no loops (do, while, for)
- no recursive functions (function f (..) {....f(...)...}
and still it diverges (fails to terminate). Whether it diverges
depends only on the function rl and its argument.
The javascript program skeleton x = ? ; while (x) y = -y ; will
terminate either rapidly or never, depending on what ? is replaced by;
and for any given ? one can reliably predict which is the case.
Current implementations of Javascript in browsers doesn't seem to allow
multiple executing scripts to access the same page's variables at the
same time (they do allow scripts to run in different pages at the same time,
but trying to fiddle with the variables of a page with a running script
seems to block in the ones I tried).
Some programs can be proven to be correct;
Yes. Turing's Halting Problem (the inability to tell if programs
terminate) doesn't quantify over the programs, but over the algorithms
trying to determine if programs halt.
It doesn't even say that there exists a program, and an input for it,
for which we cannot tell whether it halts.
It says that *whatever* algorithm you come up with, there is at least
*one* program that *that* method can't answer correctly for.
There are countably infinitly many programs. There might be a way for
each program to prove that it terminates or that it diverges (although
the proofs will have to be arbitrarily large, so there is a physical
limit). It's just that there is no way to combine all these algorithms
into one, finite program.
In practice, it very soon gets impossible to say anything with
certainty. Program analysis is the art of approximating the correct
answer to such (generally undecidable) problems as well as possible,
while only erring on the side of safety (for whatever application
it is needed for).
/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.' This thread has been closed and replies have been disabled. Please start a new discussion. |
