On Sun, 21 Feb 2010 23:17:07 -0000, Rudy Velthuis
<✉rvelthuis.de> wrote:

>> Nilling the pointer means that any further (incorrect) usage of
>> +that+ pointer will be immediately exposed by an AV.
>
> Yes. But code that uses such a pointer is badly designed:

Rudy, while I hesitate to quibble over a word you have quickly typed in a  
message in your third (fourth?) language, the fact that both you and  
Joanna frequently use the same term leads me to think that we are talking  
about different problems.


Just like Joanna used "scope" when she probably meant "lifetime", you both  
use "design" when any discussion about coding patterns is really about  
"implementation" and those two ideas - although related - are definitely  
not identical.


Even if a design were perfect (itself a big ask for any non-trivial  
project), then the probability that any implementation of that design will  
be +completely+ error-free can be demonstrated to be so low as to be  
almost indistinguishable from zero. Further, no matter how much you might  
wish it /should/ happen, for any human programmer to +fully+ understand  
any non-trivial design/implementation is not merely difficult, but  
actually - and provably - *impossible*.


(In case you dispute anything in that last paragraph, I do have three  
years' worth of postgraduate research notes and references on Software  
Engineering. Not on the whizz-bang tools, languages, and compilers but on  
the reasons why such tools have been, and still are, necessary. In  
essence, it's down to the inherent limitations of the human brain.)


Now for extremely able programmers, such as yourself and Joanna,  
experience leads to the development of coding patterns which efficiently  
and reliably implement designs - and, in a self-reinforcing feedback
loop, the reliable coding patterns themselves influence (and restrict) the  
types of design which are considered for implementation.


As time passes, this design<=>implementation feedback can lead to a state  
where certain coding constructs would look so "wrong" and "unnatural" to  
the expert that using them would be unimaginable. Not only that, but the  
brain tends to forget just how difficult and how non-obvious the learning  
process was (one reason why "expert" drivers get so annoyed when learners  
stall their cars at traffic lights)


Unfortunately, "unimaginable" (for an expert) does not mean "impossible"  
(for a novice) - or even for an expert who is distracted - or has a coffee  
cup fall on his keyboard - or suffers an IDE hiccup - or has a source file  
reverted to a backup or ...


Now, one approach is to assume that your programmers are paragons of  
perfection and will never make any mistakes - and neither will their  
colleagues; nor their IDE/compiler; nor ... And, should they ever fall  
short, "castigate them for their lack of programming skills". (This might  
be termed the Gordon Brown style of management.)


The other approach is to accept that human error is almost inevitable and  
promote more defensive coding patterns - *NOT* as any acceptance of lower  
programming standards but as an aid to the detection of as many of those  
almost-inevitable errors as early as possible in the implementation  
process.


-- 
Paul Scott
Information Management Systems
Macclesfield, UK