Re: Re: Re: Re: to strict or not to strict

Ok, challenge accepted:

-rwxrwxr--    1 cvs      cvs        143437 Oct 20  2002 mappergui.perl
+,v
[download]

This thing has 3500 lines, as you can see by the size.

It took me around 5 minutes to correct all the 'Global symbol' errors, none of which I see as critical, in fact in a GUI app I'd expect the actual GUI itself to be globally accessible. (Which is why I just threw a 'my $Mapper;' in at the top to solve those. I found one, single, misspelled variable name, which didnt surprise me in the least.. (never said I was perfect, or that the thing runs (ran) perfectly.) (Result available, should you want to see it.) BTW: Anything older than that (another year), would be unfair, I've only been using perl that long..

That this now says my code is perfect, is laughable. Unless you just mean the conformity is, it most probably still doesn't work as intended, which would be my definition of perfect.

Yes, I make typos, and I fix them, doesn't everybody? Yes I've also spent hours sometimes looking for stupid ones, that would have probably been shown using strict. I never said it didn't *work*..

As to your rant, probably/possibly. But I haven't yet, so I guess I got lucky. At least, I have some that uses lots of globals in several files, luckily more or less sensibly named. Anyway, I was talking about my preferences for my code, not other peoples. :)

Comment on Re: Re: Re: Re: to strict or not to strict Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: to strict or not to strict by liz (Monsignor) on Oct 18, 2003 at 09:49 UTC
...I found one, single, misspelled variable name.. Which I think proves what bunnyman said. That this now says my code is perfect, is laughable. But that's not what it's saying: it's only saying that 'strict' (as it were) couldn't find anything wrong with it. No more no less. The same as when Perl decides your program can be compiled, it is no guarantee that it will run correctly. It only guarantees that it will start to run. If you're lucky, it won't get an execution error before it ends. Anecdote Alert: In 1989 I was working on an editor for a system that had its roots in the beginning of the 70's. It used what you would now call a "subfile" system, in which named blocks could contain code and other data. The maximum size of such a block (which was commonly used as a subroutine) was 8K. Each line consisted of characters followed by a null byte. Once, long before, it was decided that 2 consecutive null bytes would indicate end of data: this saved having to keep the "length" of data somewhere externally. (Remember, in the early 80ies a hard-disk had the size of a dish-washer and was able to store several Megabytes!) Of course, this posed a problem for empty lines: so an empty line was basically a space with a null byte. So an empty line took 2 characters. This made the editor quite a bit more complex, but that was of course offset with faster compilation (which was on-demand per subroutine). While working this new screen-based editor (rather than the line-based editor that it used to be), I found a bug. If a block contained 8191 bytes of code (one less than what could fit in the block), it would still allow you to create a new line. But an empty line took 2 characters! So this would cause an overflow and an execution error. Unfortunately, I didn't find this problem myself, but my client did. But looking at the code, I realised that that part had basically been lifted from the older version. And lo and behold, that version also contained that error. The previous version of that editor had been in production more than 7 years at that time. And that editor was based on what had run on the mainframe before that, so it would easily add another 10 years of production to it. So why didn't anybody find that bug before? Well, since this happened in the editor, you would lose any changes you had made to that block. And I don't know about you, but I'm not able to reproduce code exactly a next time in a create process. So the next time the code would be different and the problem would not occur (you only needed one extra character to be typed to have the block fill up "properly"). I guess this episode taught me that any non-trivial program is never without bugs, no matter how long it has run in production. It also taught me that you need to create a test-suite: a properly made test-suite would have found this problem immediately. Now, in those days, there were basically no system resources to do this. Current systems do have those resources. And I can only recommend that they be used! Liz	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: to strict or not to strict
by liz (Monsignor) on Oct 18, 2003 at 09:49 UTC

...I found one, single, misspelled variable name..

Which I think proves what bunnyman said.

That this now says my code is perfect, is laughable.

But that's not what it's saying: it's only saying that 'strict' (as it were) couldn't find anything wrong with it. No more no less. The same as when Perl decides your program can be compiled, it is no guarantee that it will run correctly. It only guarantees that it will start to run. If you're lucky, it won't get an execution error before it ends.

Anecdote Alert:
In 1989 I was working on an editor for a system that had its roots in the beginning of the 70's. It used what you would now call a "subfile" system, in which named blocks could contain code and other data.

The maximum size of such a block (which was commonly used as a subroutine) was 8K. Each line consisted of characters followed by a null byte. Once, long before, it was decided that 2 consecutive null bytes would indicate end of data: this saved having to keep the "length" of data somewhere externally. (Remember, in the early 80ies a hard-disk had the size of a dish-washer and was able to store several Megabytes!)

Of course, this posed a problem for empty lines: so an empty line was basically a space with a null byte. So an empty line took 2 characters.

This made the editor quite a bit more complex, but that was of course offset with faster compilation (which was on-demand per subroutine).

While working this new screen-based editor (rather than the line-based editor that it used to be), I found a bug. If a block contained 8191 bytes of code (one less than what could fit in the block), it would still allow you to create a new line. But an empty line took 2 characters! So this would cause an overflow and an execution error.

Unfortunately, I didn't find this problem myself, but my client did. But looking at the code, I realised that that part had basically been lifted from the older version. And lo and behold, that version also contained that error.

The previous version of that editor had been in production more than 7 years at that time. And that editor was based on what had run on the mainframe before that, so it would easily add another 10 years of production to it.

So why didn't anybody find that bug before? Well, since this happened in the editor, you would lose any changes you had made to that block. And I don't know about you, but I'm not able to reproduce code exactly a next time in a create process. So the next time the code would be different and the problem would not occur (you only needed one extra character to be typed to have the block fill up "properly").

I guess this episode taught me that any non-trivial program is never without bugs, no matter how long it has run in production.

It also taught me that you need to create a test-suite: a properly made test-suite would have found this problem immediately. Now, in those days, there were basically no system resources to do this. Current systems do have those resources. And I can only recommend that they be used!

Liz

[reply]