I am looking for a definition of "defensive programming" (DP) and am
very disappointed in what I find. In general I find very little on the
subject. Much of what I find confuses DP with Design by Contract (DbC),
even though Meyer says that they are different in OOSC(ii). I asked
Bertrand Meyer for a reference a while ago, here is his reply:
--
I think that when I was writing
OOSC one of the references I had in mind regarding
defensive programming was the method advocated in
Liskov and Guttag's book "Abstraction and Specification
in Program Development" which makes a strong case
for this approach.
--
Unfortunately, that book seems to no longer be availanle.
Any ideas?

From:	CTips
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 11:25:37 -0500

apm35@student.open.ac.uk wrote:
> I am looking for a definition of "defensive programming" (DP) and am
> very disappointed in what I find. In general I find very little on the
> subject. Much of what I find confuses DP with Design by Contract (DbC),
> even though Meyer says that they are different in OOSC(ii). I asked
> Bertrand Meyer for a reference a while ago, here is his reply:
> --
> I think that when I was writing
> OOSC one of the references I had in mind regarding
> defensive programming was the method advocated in
> Liskov and Guttag's book "Abstraction and Specification
> in Program Development" which makes a strong case
> for this approach.
> --
> Unfortunately, that book seems to no longer be availanle.
> Any ideas?
>

See http://users.bestweb.net/~ctips for some defensive programming
techniques, many specific to C.

IMO, defensive programming is adding code or adopting a coding style to
prevent mistakes and/or catch mistakes as early as possible [move errors
from run-time to compile-time or have a bug exhibit a visible symptom
eariler in the run of the program].

The confusion between defensive programming and DbC arises because an
(added) code fragment can sometimes be justified by either approach.

For instance, consider the following function
unsigned
factorial(
unsigned n
)
{
assert( n <= 12 ); /* n! needs more than 32 bits for n > 12 */
return n <= 1? 1: n*factorial(n-1);
}

Is the assert() statement an instance of defensive programming, or a
check for the contract conditions?

From:	Andrew Peter Marlow
Subject:	Re: definition of defensive programming?
Date:	Sat, 15 Jan 2005 23:56:04 +0000

On Thu, 13 Jan 2005 11:25:37 -0500, CTips wrote:
> apm35@student.open.ac.uk wrote:
>> I am looking for a definition of "defensive programming" (DP) and am
>> very disappointed in what I find. In general I find very little on the
>> subject. Much of what I find confuses DP with Design by Contract (DbC),
>
> For instance, consider the following function
> unsigned
> factorial(
> unsigned n
> )
> {
> assert( n <= 12 ); /* n! needs more than 32 bits for n > 12 */
> return n <= 1? 1: n*factorial(n-1);
> }
>
> Is the assert() statement an instance of defensive programming, or a
> check for the contract conditions?

The above is DbC. The assert is being used to check the precondition.

-Andrew Marlow

From:	CTips
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 10:29:44 -0500

Andrew Peter Marlow wrote:
> On Thu, 13 Jan 2005 11:25:37 -0500, CTips wrote:
>
>>apm35@student.open.ac.uk wrote:
>>
>>>I am looking for a definition of "defensive programming" (DP) and am
>>>very disappointed in what I find. In general I find very little on the
>>>subject. Much of what I find confuses DP with Design by Contract (DbC),
>>
>>For instance, consider the following function
>> unsigned
>> factorial(
>> unsigned n
>> )
>> {
>> assert( n <= 12 ); /* n! needs more than 32 bits for n > 12 */
>> return n <= 1? 1: n*factorial(n-1);
>> }
>>
>>Is the assert() statement an instance of defensive programming, or a
>>check for the contract conditions?
>
>
> The above is DbC. The assert is being used to check the precondition.
>
> -Andrew Marlow
>

What if the requirement on the factorial() is that n <= 10?

In that case DbC would add:
assert( n <= 10 );
NOT
assert( n <= 12 );

In other words, you can't tell whether the assert() was added for DbC or DP.

From:	Marc Girod
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 16:08:23 GMT

>>>>> "CTips" == CTips writes:

CTips> In other words, you can't tell whether the assert() was added
CTips> for DbC or DP.

This is because DbC has drifted from its original goals.
The intention was not to add explicit code which would be checked
dynamically.

This is what I got from Meyer's /Introduction to the Theory of
Programming Languages/, the chapter on /Axiomatizing programming
languages/ about the difference between assertions and boolean
expressions, pp 312-313:

.. Boolean expressions appear *in* programs: they belong to the
programming language.
.. Assertions express properties *about* programs: they belong to the
formulae of the axiomatic theory.

Eiffel assertions are actually both DP *and* DbC, not 'pure' DbC.
I surmise that at some point, the customer pressure was too strong to
be resisted.
The code snippet was actually C, with the assert macro. It is DP more
than DbC (communicating between humans about the semantics by other
means than running the program under various test conditions).

--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia BI 00045 NOKIA Group Mobile: +358-50 38 78415
Valimo 21 / B616 Finland Fax: +358-71 80 64474

From:	Andrew Peter Marlow
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 16:36:28 +0000

On Sun, 16 Jan 2005 16:08:23 +0000, Marc Girod wrote:
>>>>>> "CTips" == CTips writes:
>
> CTips> In other words, you can't tell whether the assert() was added
> CTips> for DbC or DP.
>
> This is because DbC has drifted from its original goals.
> The intention was not to add explicit code which would be checked
> dynamically.

I agree that the intention was not to add explicit code.
But one has to add code for languages that do not have
explicit DbC support. The code in question was C, which
does not have direct support for DbC.

> This is what I got from Meyer's /Introduction to the Theory of
> Programming Languages/, the chapter on /Axiomatizing programming
> languages/ about the difference between assertions and boolean
> expressions, pp 312-313:

I agree, but Meyer invented a language that has support for this, Eiffel.

> Eiffel assertions are actually both DP *and* DbC, not 'pure' DbC. I
> surmise that at some point, the customer pressure was too strong to be
> resisted.

I disagree. IMO Eiffel assertions are pure DbC. They do not appear
in the code, they appear in the axioms, i.e. the preconditions,
postconditions and class invariants.

> The code snippet was actually C, with the assert macro. It is DP more
> than DbC (communicating between humans about the semantics by other
> means than running the program under various test conditions).

I disagree. It might seem like DP superficially but that's
mainly because C does not directly support DbC.
IMO languages that do not directly support DbC can still
use DbC principles by adding explicit code such as was
done here for the factorial precondition.

From:	Marc Girod
Subject:	Re: definition of defensive programming?
Date:	Mon, 17 Jan 2005 15:11:08 GMT

>>>>> "AM" == Andrew Peter Marlow writes:

AM> I disagree. IMO Eiffel assertions are pure DbC. They do not appear
AM> in the code, they appear in the axioms, i.e. the preconditions,
AM> postconditions and class invariants.

And you mean that they are not part of "the code"...
I'd have to look again closer at Eiffel "non-code", and "code" parts.

Anyway, to me, something which is being executed at run-time. or even
affects the run-time behaviour, is code (this is criterion #1).

AM> I disagree. It might seem like DP superficially but that's
AM> mainly because C does not directly support DbC.
AM> IMO languages that do not directly support DbC can still
AM> use DbC principles by adding explicit code such as was
AM> done here for the factorial precondition.

I believe we do indeed disagree.
Beyond being run, C assertions are explicitly in the software text.
That's criterion #2 for defining 'code'.
This has a cost, the same as comments (the "avoid documentation"
principle -- which is of course a tradeoff).

There is a risk that we are discussing the of angels here.

DbC relates to me to static typing. They are a way to express
semantics in a dimension orthogonal to run-time.
Run-time semantics relate to testing. I believe it is a good idea to
keep the two distinct, for reasons which become clear when the
configuration changes (module integration, distribution, environment
changes, evolution...).

AFAIK, Eiffel didn't keep the two separate, despite the original
intentions.

--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia BI 00045 NOKIA Group Mobile: +358-50 38 78415
Valimo 21 / B616 Finland Fax: +358-71 80 64474

From:	Andrew Peter Marlow
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 16:01:00 +0000

On Sun, 16 Jan 2005 10:29:44 -0500, CTips wrote:
>>>For instance, consider the following function
>>> unsigned factorial (unsigned n)
>>> {
>>> assert( n <= 12 ); /* n! needs more than 32 bits for n > 12 */
>>> return n <= 1? 1: n*factorial(n-1);
>>> }
>>>Is the assert() statement an instance of defensive programming, or a
>>>check for the contract conditions?
>> The above is DbC. The assert is being used to check the precondition.
>>
>> -Andrew Marlow
>
> What if the requirement on the factorial() is that n <= 10?
> In that case DbC would add:
> assert( n <= 10 );
> NOT
> assert( n <= 12 );
> In other words, you can't tell whether the assert() was added for DbC or DP.

If the requirement on the factorial() is that n <= 10
then you have changed the precondition to be that n <= 10
so you say assert( n <= 10 ); instead of assert( n <= 12 );.
This is still checking the precondition so it is still DbC.

From:	Alexei A. Polkhanov
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 08:46:54 -0800

I don't think there is such an official term as Defensive Programming
even if it can be found in Wikipedia, but it is more of long-lived
idiom. What really have been developed over time is a Design by Contract
well described here and in many other sources:
http://www.bon-method.com/index_normal.htm

Nice idea to add constraints to programming language was implemented in
Eiffel where defining an interface for member function one can specify
set of pre- and post- conditions. Common practice to have "assert()" in
C code also one of methods of defensive programming. Restrictions on use
of loop index in Ada also can be considered as built-in support for
defensive programming.

I would define Defensive Programming as an methods and constructs used
to ensure contractual consistency between untrusted blocks of code in
programming languages which do not directly support Design by Contract
methodology.

Alexei.

apm35@student.open.ac.uk wrote:
> I am looking for a definition of "defensive programming" (DP) and am
> very disappointed in what I find. In general I find very little on the
> subject. Much of what I find confuses DP with Design by Contract (DbC),
> even though Meyer says that they are different in OOSC(ii). I asked
> Bertrand Meyer for a reference a while ago, here is his reply:
> --
> I think that when I was writing
> OOSC one of the references I had in mind regarding
> defensive programming was the method advocated in
> Liskov and Guttag's book "Abstraction and Specification
> in Program Development" which makes a strong case
> for this approach.
> --
> Unfortunately, that book seems to no longer be availanle.
> Any ideas?
>

From:	CTips
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 13:42:11 -0500

Alexei A. Polkhanov wrote:

>
> I would define Defensive Programming as an methods and constructs used
> to ensure contractual consistency between untrusted blocks of code in
> programming languages which do not directly support Design by Contract
> methodology.
>
> Alexei.

I think you're being overly restrictive. For instance, for C, I consider
using
if( 0 == x )
instead of
if( x == 0 )

or writing
if( p ) {
foo();
}
instead of
if( p )
foo();

as (possibly trivial) instances of defensive programming which have
nothing to do with DbC.

From:	Bjorn Reese
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 21:39:33 +0100

CTips wrote:

> I think you're being overly restrictive. For instance, for C, I consider
> using
> if( 0 == x )
> instead of
> if( x == 0 )
[ example snipped ]
> as (possibly trivial) instances of defensive programming which have
> nothing to do with DbC.

The above are not examples of defensive programming as the software
will not run more or less robustly in either case; it will be the
same. Your examples are more about maintenance, which is an important,
but different, topic.

In another post you mentioned assertions. These are, IMHO, not part
of defensive programming because (1) they may terminate the software,
and (2) they may or may not be active in the software. The defensive
programming example of your factorial code would be something like
this:

unsigned factorial(unsigned n)
{
if (n > 12)
return SOME_ERROR_CODE;
return (n <= 1) ? 1 : n * factorial(n - 1);
}

--
mail1dotstofanetdotdk

From:	Vitaly Rudovich
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 14:57:08 +0100

From:	David Lightstone
Subject:	Re: definition of defensive programming?
Date:	Thu, 13 Jan 2005 15:02:24 GMT

"Vitaly Rudovich" wrote in message
news:34ncssF4b14c0U1@individual.net...
> apm35@student.open.ac.uk wrote:
> > I am looking for a definition of "defensive programming" (DP) and am
> > very disappointed in what I find. In general I find very little on the
> > subject. Much of what I find confuses DP with Design by Contract (DbC),
> > even though Meyer says that they are different in OOSC(ii). I asked
> > Bertrand Meyer for a reference a while ago, here is his reply:
>
> http://en.wikipedia.org/wiki/Defensive_programming
>
> | Defensive programming is a form of defensive design intended to
> | ensure the continuing function of a piece of software in spite
> | of unforeseeable usage of said software.
>

I am amused by the concept. It is sort of like defensive driving. You know
some fool will make a mistake. The choice is yours, die, be mamed, or live
injury free. If it doesn't matter, by all means write code that will fail

From:	Andrew Peter Marlow
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 16:27:51 +0000

On Thu, 13 Jan 2005 15:02:24 +0000, David Lightstone wrote:
>> | Defensive programming is a form of defensive design intended to
>> | ensure the continuing function of a piece of software in spite
>> | of unforeseeable usage of said software.
>
> I am amused by the concept. It is sort of like defensive driving. You know
> some fool will make a mistake. The choice is yours, die, be mamed, or live
> injury free. If it doesn't matter, by all means write code that will fail

I assume you think DP is an obvious precaution to take?
"For my own safety I am going to assume that all other
drivers are nutters? After all, better to be safe than sorry..."
I do like DP but IMO this is an extreme position.
It is the opposite of the DbC extremists that might say
"if all driver drove sensibly then you wouldn't need to
take all these redundant precautions".

I use DP to help me form contracts that my callers will find
more agreeable then kind of contract most DbC advocates would draw up.
These contracts tend to have more liberal pre-conditions and come with an
explicit error strategy that enables the caller to know what to do in the
event of a pre-condition violation or a post-condition violation. I use
exceptions in the event of pre-condition violation and may use either
error codes or exceptions for post-condition violations depending on how
near or far I expect any error handling to be to the code that calls me.

I use assertions for class invariants. I don't use them
as part of DP. I prefer to deflect an error or have
a more liberal contract rather than have a pre-condition violation.

From:	David Lightstone
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 20:16:05 GMT

"Andrew Peter Marlow" wrote in message
news:pan.2005.01.16.16.27.51.383817@marlowa.plus.com...
> On Thu, 13 Jan 2005 15:02:24 +0000, David Lightstone wrote:
> >> | Defensive programming is a form of defensive design intended to
> >> | ensure the continuing function of a piece of software in spite
> >> | of unforeseeable usage of said software.
> >
> > I am amused by the concept. It is sort of like defensive driving. You
know
> > some fool will make a mistake. The choice is yours, die, be mamed, or
live
> > injury free. If it doesn't matter, by all means write code that will
fail
>
> I assume you think DP is an obvious precaution to take?

I trained as a mathematician. I would prefer to have the rigor of a
mathematical proof, but recognize the impossibility of achieving such a
goal. Why is such a goal impossible to achieve? Incompetance, expediency
..... ?

The old joke, 1 is prime, 2 is prime, 3 is prime, 4 can be divide by 2 so it
must be an experimantal error, 5 is prime, so all numbers are prime is
generally applicable. That is software developers and their managers
tolerates error conditions when they know they should not. The choice
tolerate, not tolerate is yours. Whatever you choose to call the decision to
tolerate is up to you. Defensive programming implies tolerate is not an
acceptable decision.

> "For my own safety I am going to assume that all other
> drivers are nutters? After all, better to be safe than sorry..."
> I do like DP but IMO this is an extreme position.
> It is the opposite of the DbC extremists that might say
> "if all driver drove sensibly then you wouldn't need to
> take all these redundant precautions".
>
> I use DP to help me form contracts that my callers will find
> more agreeable then kind of contract most DbC advocates would draw up.
> These contracts tend to have more liberal pre-conditions and come with an
> explicit error strategy that enables the caller to know what to do in the
> event of a pre-condition violation or a post-condition violation. I use
> exceptions in the event of pre-condition violation and may use either
> error codes or exceptions for post-condition violations depending on how
> near or far I expect any error handling to be to the code that calls me.
>
> I use assertions for class invariants. I don't use them
> as part of DP. I prefer to deflect an error or have
> a more liberal contract rather than have a pre-condition violation.
>

From:	shelley at osel.netkonect.co.uk
Subject:	Re: definition of defensive programming?
Date:	14 Jan 2005 02:42:04 -0800

apm35@student.open.ac.uk wrote:
> I am looking for a definition of "defensive programming" (DP) and am
> very disappointed in what I find. In general I find very little on
the
> subject. Much of what I find confuses DP with Design by Contract
(DbC),
> even though Meyer says that they are different in OOSC(ii). I asked
> Bertrand Meyer for a reference a while ago, here is his reply:
> --
> I think that when I was writing
> OOSC one of the references I had in mind regarding
> defensive programming was the method advocated in
> Liskov and Guttag's book "Abstraction and Specification
> in Program Development" which makes a strong case
> for this approach.
> --
> Unfortunately, that book seems to no longer be availanle.
> Any ideas?

Sommerville describes defensive programming as:

"...an approach to program development whereby programmers assume that
there may be undetected faults in their programs. Redundant code is
incorporated to check the system state after modification and to ensure
that the state change is consistent If inconsistencies are detected the
state change is retracted or the state is restored to a known correct
state."

He then goes on to say it is an approach to fault tolerance using the
techniques of, detecting failure, damage assessment and recovering from
failure.

I had assumed an alternative and more limited description: designing
the code to manage gracefully any inputs that it received, where
gracefully depended on the application and the requirements, and ranged
from fail safe to helpful error messages. Michael Jackson's JSP
encouraged this description of defensive programming.

From:	Andrew Gabb
Subject:	Re: definition of defensive programming?
Date:	Mon, 17 Jan 2005 00:03:05 +1030

shelley@osel.netkonect.co.uk wrote:
> Sommerville describes defensive programming as:
>
> "...an approach to program development whereby programmers assume that
> there may be undetected faults in their programs. Redundant code is
> incorporated to check the system state after modification and to ensure
> that the state change is consistent If inconsistencies are detected the
> state change is retracted or the state is restored to a known correct
> state."

I'd agree with the definition, more or less, but the remainder is
just one solution, not requirement, and muddies the issue (typical
of too much SwE advice and too much SwE for that matter).

From memory, the concept of defensive programming was originally
put forward in the 70s to counter the trend (still true) that
programmers are too optimistic and don't consider the almost certain
probability that their software contains defects. There were many
aspects of defensive programming including the use of reviews,
assertions, exceptions, compensatory code, etc., etc.

Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----

From:	Marc Girod
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 14:39:29 GMT

>>>>> "AG" == Andrew Gabb writes:

AG> From memory, the concept of defensive programming was originally
AG> put forward in the 70s to counter the trend (still true) that
AG> programmers are too optimistic and don't consider the almost
AG> certain probability that their software contains defects.

In my memory, the connotations were soon negative (as enforced by
the analogy of "defensive management" in PeopleWare, by De
Marco/Lister).

Defensive programming was something to avoid, resulting in additional
complexity, various costs and finally loss of quality.

Making it *clearly* unnecessary became a challenge of language design.
This was part of the rationale for both exceptions and assertions à la
DbC.

--
Marc Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia BI 00045 NOKIA Group Mobile: +358-50 38 78415
Valimo 21 / B616 Finland Fax: +358-71 80 64474

From:	Andrew Peter Marlow
Subject:	Re: definition of defensive programming?
Date:	Sun, 16 Jan 2005 16:13:45 +0000

On Sun, 16 Jan 2005 14:39:29 +0000, Marc Girod wrote:
>>>>>> "AG" == Andrew Gabb writes:
> In my memory, the connotations were soon negative (as enforced by
> the analogy of "defensive management" in PeopleWare, by De
> Marco/Lister).
>
> Defensive programming was something to avoid, resulting in additional
> complexity, various costs and finally loss of quality.

This is the view of Meyer and of DbC. Meyer says in OOSC(ii),
defensive programming == offensive programming.
The redundant checks, extra code, and possible performance
impact were the 'offence' as far as he was concerned.
My view is that DP is useful; it is a useful counterweight
to the excesses of DbC. When DbC is not tempered with DP,
I find that restrictive contracts result, causing the
check that might be central to be replicated in each client.
This too is extra code with attendant peformance implications.

I also find that DbC advocates tend to create contracts
that verge on the arrogant -- "if the user calls me wrongly
then he gets what he deserves!". Typically this would be
a precondition violation which, if handled using the C assert
macro, would lead to a core dump. The DbC advocate is unrepentant:
the core dump is the callers punishment for being wrong.
I think that a better approach is have use a combination of
DP and DbC techniques.

From:	Andrew Hardy
Subject:	Re: definition of defensive programming?
Date:	Mon, 17 Jan 2005 11:14:10 +0000

apm35@student.open.ac.uk wrote:
> I am looking for a definition of "defensive programming" (DP) and am
> very disappointed in what I find. In general I find very little on the
> subject. Much of what I find confuses DP with Design by Contract (DbC),
> even though Meyer says that they are different in OOSC(ii). I asked
> Bertrand Meyer for a reference a while ago, here is his reply:
> --
> I think that when I was writing
> OOSC one of the references I had in mind regarding
> defensive programming was the method advocated in
> Liskov and Guttag's book "Abstraction and Specification
> in Program Development" which makes a strong case
> for this approach.
> --
> Unfortunately, that book seems to no longer be availanle.
> Any ideas?
>
Personally...

I think of DbC as 'assertions' - if you pass a value to me outside of my
contract, I'll kill it with an assertion.

If I wrote a piece of DP, I'd be trying to work around the bad value.

e.g. My routine expects to receive a date 'string' in the format
DDMMYYYY and for that to represent a 'valid' date.

For DbC, if the received string were in the format 'DD/MM/YYYY' I'd
simply stop the program.

For DP, I'd possibly have anticipated that someone would send a date in
a format other than the expected - so I'd have some code to work out
which format was used and then convert the given string to one that the
rest of the routine could work with.

From:	apm35 at student.open.ac.uk
Subject:	Re: definition of defensive programming?
Date:	13 Jan 2005 10:53:13 -0800

CTips wrote:
> Alexei A. Polkhanov wrote:
> > I would define Defensive Programming as an methods and constructs
used
> > to ensure contractual consistency between untrusted blocks of code
in
> > programming languages which do not directly support Design by
Contract
> > methodology.
> I think you're being overly restrictive. For instance, for C, I
consider
> using
> if( 0 == x )
> instead of
> if( x == 0 )
>
> or writing
> if( p ) {
> foo();
> }
> instead of
> if( p )
> foo();
>
> as (possibly trivial) instances of defensive programming which have
> nothing to do with DbC.
Indeed. This is IMO a good example of defending against coding error.