Top warning signs of bad code?

[Henrik]

Re: Top warning signs of bad code?

Randy Webb skrev:
[color=blue]
> Henrik wrote:[color=green]
> >
> > Then I wonder what you mean by '"well-tested" may be a subset of
> > "seems to work"'. I have probably misunderstood that period.[/color]
>
> [snip]
>
> Makes the well-tested a subset of "seems to work".[/color]

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

[Mark Preston]

Re: Top warning signs of bad code?

Randy Webb wrote:[color=blue]
> Henrik wrote:
>[color=green]
>> 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.[/color]
>
>
> 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.
>[/color]
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".

[Lasse Reichstein Nielsen]

Re: Top warning signs of bad code?

Mark Preston <usenet@nosourc e.co.uk> writes:
[color=blue]
> 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).[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

Re: Top warning signs of bad code?

In article <ocF2LTJvMXUBFw qo@merlyn.demon .co.uk>, Dr John Stockton
<spam@merlyn.de mon.co.uk> writes

<snip>[color=blue]
>We're not talking about whether the code on the page is arithmetically
>reliable, but whether it is worth copying.[/color]

When you aren't sure that the code is arithmetically reliable you can't
possibly say that it's worth your copying it.
[color=blue]
>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.[/color]

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.
[color=blue]
>Something which is easily to pre-calculate should be calculated at
>authoring time, rather than at execution time.[/color]
<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

[Richard Cornford]

Re: Top warning signs of bad code?

Michael Winter wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green]
>> 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.[/color]
>
> Hmm, so it does.
>
> I must say I'm confused (so excuse the befuddled thought
> process that follows). Why exactly is this syntax supported?[/color]

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).
[color=blue]
> 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.[/color]

Yes, there is absolutely no need to be using parentheses around
collection indexes instead of brackets. And the standards go with
brackets only.
[color=blue]
> Is it then just a coping measure for IE's collections?[/color]

I think so.
[color=blue]
> Even so, that then raises the question for why
> Microsoft[1] decided to allow parentheses for
> something that is so much like an array.[/color]
<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.

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <opsesrbjy0x13k vk@atlantis>, dated Thu, 23 Sep 2004
20:30:03, seen in news:comp.lang. javascript, Michael Winter <M.Winter@bl
ueyonder.co.inv alid> posted :[color=blue]
>On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton
><spam@merlyn.d emon.co.uk> wrote:
>
>[snip]
>[color=green]
>> One need only add "unless scripting is fundamental"; consider, for
>> example, <URL:http://www.merlyn.demo n.co.uk/astro.htm#Calc> as if it
>> were a complete page. Without script, it serves only to show what it
>> cannot do.[/color]
>
>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.[/color]

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?<g etTime> .

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Andrew Thompson]

Re: Top warning signs of bad code?

On Fri, 24 Sep 2004 14:12:16 +0100, Dr John Stockton wrote:
[color=blue]
> ..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.[/color]

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

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <HstufWEDpzUBFw Nx@jgharris.dem on.co.uk>, dated Thu, 23
Sep 2004 22:04:03, seen in news:comp.lang. javascript, John G Harris
<john@nospam.de mon.co.uk> posted :[color=blue]
>
>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.[/color]

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.demo n.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.idiotsdelig ht.net/minitrue/> Update hope?

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <cj1ep0$ilg$1$8 30fa17d@news.de mon.co.uk>, dated Fri, 24
Sep 2004 16:40:29, seen in news:comp.lang. javascript, Mark Preston
<usenet@nosourc e.co.uk> posted :
[color=blue]
>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).[/color]


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.demo n.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demo n.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demo n.co.uk/batfiles.htm> - also batprogs.htm.

[Lasse Reichstein Nielsen]

Re: Top warning signs of bad code?

Dr John Stockton <spam@merlyn.de mon.co.uk> writes:

[Turing][color=blue]
> 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.[/color]

Almost (I'll go off on that tangent at the end :)
[color=blue]
> A program of finite length and without loops will clearly stop in a
> finite time.[/color]

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(rec Arr));
// 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.
[color=blue]
> 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.[/color]

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).
[color=blue]
> Some programs can be proven to be correct;[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

Re: Top warning signs of bad code?

In article <9AdzMtNLWKVBFw xe@merlyn.demon .co.uk>, Dr John Stockton
<spam@merlyn.de mon.co.uk> writes[color=blue]
>JRS: In article <HstufWEDpzUBFw Nx@jgharris.dem on.co.uk>, dated Thu, 23
>Sep 2004 22:04:03, seen in news:comp.lang. javascript, John G Harris
><john@nospam.d emon.co.uk> posted :[color=green]
>>
>>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.[/color]
>
>No good reason *for you*.[/color]
<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 misunderstandin gs 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

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <LihNc9A1vcVBFw 0D@jgharris.dem on.co.uk>, dated Sat, 25
Sep 2004 20:50:13, seen in news:comp.lang. javascript, John G Harris
<john@nospam.de mon.co.uk> posted :[color=blue]
>In article <9AdzMtNLWKVBFw xe@merlyn.demon .co.uk>, Dr John Stockton
><spam@merlyn.d emon.co.uk> writes[color=green]
>>JRS: In article <HstufWEDpzUBFw Nx@jgharris.dem on.co.uk>, dated Thu, 23
>>Sep 2004 22:04:03, seen in news:comp.lang. javascript, John G Harris
>><john@nospam. demon.co.uk> posted :[color=darkred]
>>>
>>>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.[/color]
>>
>>No good reason *for you*.[/color]
> <snip>
>
>By now everyone realises, I hope, that this is a discussion about
>different reasonable coding styles, not about good code and bad code.[/color]

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.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[bruce]

Re: Top warning signs of bad code?

jim@jibbering.c om (Jim Ley) wrote in message news:<4151a064. 160114883@news. individual.net> ...[color=blue]
> On 22 Sep 2004 07:51:48 -0700, bruce_brodinsky @glic.com (bruce) wrote:
>[color=green]
> >Being in a practical business environment,[/color]
>
> Lots of us are in the same environment you know...
>[color=green]
> > 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.[/color]
>
> 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.[/color]


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.

[Thomas 'PointedEars' Lahn]

Re: Top warning signs of bad code?

Richard Cornford wrote:
[color=blue]
> href="javascrip t:somefunction( )" - wouldn't appear in HTML written
> by the informed/experienced, so
> can be stated as bad.[/color]

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

[Richard Cornford]

Re: Top warning signs of bad code?

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>>href="javascr ipt:somefunctio n()" -wouldn't appear in HTML written
>> by the informed/experienced, so
>> can be stated as bad.[/color]
>
> Intrinsic event handler attributes have been introduced in HTML 4.01[/color]

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.
[color=blue]
> and will not work in HTML 3.2 user agents,[/color]

Then you can name those user agents?
[color=blue]
> while a `javascript:' URI will work.[/color]

Javascript URIs have never worked on UAs that do not support scripting
with javascript.
[color=blue]
> Exactly the informed/experienced will use the above
> construct to support HTML 3.2 user agents, too,[/color]

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="javascrip t: ... ") is below the threshold of real world and
commercial scripting (so clean degradation on those UAs if the
preferable option).
[color=blue]
> i.e. your statement is false.[/color]

Not as worded.

<snip>[color=blue]
> The presence of javascript: URIs in source code alone
> cannot be considered an indicator for bad style;[/color]

HTML source code is specified in my statement.
[color=blue]
> that depends on the context.[/color]
<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.