Good point. The '10.000 bugs' claim, or in my words the 'one bug per line' claim, assumes a broad definition of a 'bug'. Some examples that come to mind:

A syntax error. This is the most common bug and most of them are repaired before the product ships. If they are all included in the count, then one-per-line is even too optimistic.

A wrong order of the actions. E.g. a file's existence is indeed checked, but a preceding piece of code already assumed it to be present.

Not checking conditions. E.g. a table is opened, but its existence has not been checked beforehand. I once wrote here on the UT about my 'Thundering Train' concept, the idea that one ought to check the conditions before the train departs, but might no longer do this while the train is riding at high speed, in order to indeed ride at high speed. Such a way of programming is okay for many applications in my opinion, but others might regard it as irresponsible and totally buggy code.

Not checking ALL conditions. There are always so many conditions that both the analist and the developer are not aware of. The blind sports are abundant.

Logical flaws, or logical fallacies. I make them every day again, many times. I no longer feel ashamed if somebody confronts me with such a fallacy. On the contrary, I thank them for it.

Wrong assumptions. E.g. this week my colleague wrote in documentation that employees had the right for an half hour pause when the shift is longer than 4.5 hours. I told him that it should be 'equal or longer' than 4.5 hours. It appeared that I was wrong and he was right. This wrong assumption has been in my brains for many years and I can only hope it didn't lead to wrong code.

What can we do about this all? Well, for one thing reviewing each others work is the least what we should do! Frther, be cautious, be precise, be experienced, be the master of the code (that is, stay in control of it).



>Depends what you call a bug.
>
>If you run a program on a system that is almost out of RAM or disk space, pretty much any command could cause a crash. Does that mean those commands are buggy?
>
>>One bug per line? I don't dispute that there are lots of software bugs (reportedly Microsoft Word 3.0 shipped with 3000 known bugs) but hat sounds awfully high.
>>
>>>LOL
>>>
>>>I won't claim I'm still finding bugs on a daily basis, but two in this one week, yes. Oh well, I'm quite aware that the software I write is full of mistakes -- users regularly find bugs that survived over 10 years without anyone noticing it as a bug -- they oftentimes think it's normal behavior.
>>>
>>>I somewhere red that an average packet contains 10.000 bugs. An unbelievable amount, but the more experienced I become the more I get the idea that it is true. There's probably one bug per line of code.
>>>
>>>>It turns out, neither VFP nor its documentation are perfect!
>>>>
>>>>The VFP documentation and debug teams are feverishly working on this issue as we speak!
>>>>
>>>>/kidding
>>>>
>>>>>Hi James,
>>>>>
>>>>>Well then, why is this not in the documentation?! It is very important to know this, isn't it. I can say I'm a really experienced vfp developer, doing vfp since 1990. But this has never been told or explained to me, nowhere, not in the docs, not in the Hackers guide. 'By-design' may be what has been told to you, but to me that sounds like a rationalisation, to hide the real reason: a design flaw or simply a blind spot for this when implementing it, in both cases a flaw they somehow didn't want to repair.
>>>>>
>>>>>Re-using the cached version of a previously instantiated object is smart enough, but of course that should not imply the re-use of any initial values.
>>>>>
>>>>>>Peter --
>>>>>>
>>>>>>By design.
>>>>>>
>>>>>>FoxPro does neat things with caching classes you have referenced so it does not have to re-create them from
>>>>>>scratch every time you use them.
>>>>>>
>>>>>>This is the same problem experienced in VCX-based classes where the property value is created with an '=',
>>>>>>which is executed the first time the class is created only.
>>>>>>
>>>>>>>Hi all,
>>>>>>>
>>>>>>>In the code hereunder the nStart property is set to the value of seconds() at the moment of creating the object. However, if I create another instance of the object (while the first is still active) the property does not get the value of seconds() of the moment of creation, but appears to be totally equal to the property of the first instance!
>>>>>>>
>>>>>>>I imagine I can get around this by redeclaring it in the Init(). But why is this happening? Another bug or 'just' a quirck? Or is it by-design??
>>>>>>>
>>>>>>>

DEFINE CLASS cusLogFileHandler AS custom
>>>>>>>	
>>>>>>>	nHandle    = 0
>>>>>>>	nErrors    = 0
>>>>>>>	dStart     = date()		&& start date - required for calculation of elapsed time
>>>>>>>	nStart     = seconds()
>>>>>>>	cFileName  = ""
>>>>>>>
>>>>>>>	PROCEDURE init( tcFileName, tlNew )
>>>>>>>		local lcWhat
>>>>>>>
>>>>>>>		with this
>>>>>>>			*
>>>>>>>