Too Many Assertions?

[Jefffff]

Regarding the use of assertions:
According to Juval Lowy's excellent coding standards document (PDF download
available at www.idesign.net), every assumption in your code should have an
assertion... and on average, every 5th line is an assertion.

My question:
Do any of you include that many assertions? I agree in principle that we
should code defensively, but his recommendation just seems to go "overboard"
and would result in a lot of bloated code. If followed, the recommendation
would result in something like 20% more code.

Thoughts? Opionions? Perspective?

Thanks!

 

[Ward Bekker]

Hi Jeff,

I think it's a matter of balance. My own guideline is to have a lot of
asserts that checks the arguments of a method are as expected. And for
every method that I call from that method, I'll verify their result as
well. Especially when you program calls a method from an external
component, then you should double check the output as external
components tend to release new versions that behave just a bit
differently than the older version without telling so in their release
notes.

Just writing an assert every 5th line is not very pragmatic. I look at
it as a kind of build-in defense system that warns you as a developer
for possible new bugs when changing parts of the program. So, build your
defenses where it makes most sense.

--
Ward Bekker
"Asp.Net Discussions for the Professional Developer"
http://www.dotnettaxi.com

"Free .Net 2.0 C# to/from VB.Net Code Converter"
http://www.dotnettaxi.com/Tools/Converter.aspx

 

[Marius Groenendijk]

Jeff,
We usually assert Pre-conditions of methods.
So the first few lines of a method may be bunch of asserts on the params.
Post-conditions are a bit trickier.
In our experience, if you consistently check pre-conditions you can
almost always forget about the post-conditions.
If you really really need to check the post-condition of a method
you could also do that in the caller of the method. So here, indeed
you'd end up 'sprinkling' asserts throughout the code.

Definitely combine asserts with Unit Testing and FxCop

Don't worry about overhead/bloat, in release builds asserts are gone.

HTH,
Marius.

 

[Clive Dixon]

I was also a bit surprised by that statement (read it in Juval's excellent
"Programming .NET Components").

Having said that, I do put a massive number of assertions in my code
compared to my peers (though not as much as 20% of lines!). The bottom line
is that many bugs in my code get caught and pinpointed very quickly, and it
serves to make my code generally far more reliable than that of my peers
IMHO. Also, combined with genuinely meaningful error messages, it means that
when other developers use my components and have not RTFM (OK, RTF C#
XML/NDoc documentation) it tells them precisely what they have done wrong
and they don't come to me telling me that my component has a "bug".

It does clutter source code, but #region/#endregion is your friend.

 

[cody]

Although one should use ArgumentExceptions to handle method arguments.
Assertion should be used only for theoretically impossible conditions in the
code that has nothing to do with external conditions like parameters, when
and how which methods are called or external ressources like files.

But yes - this is only theory. Often programmer prefer assertions because
they can't crash code in release mode as exceptions do and they do not
affect performance in release mode.

 

[Jon Skeet [C# MVP]]

<"Marius Groenendijk" <Marius Groenendijk (Hotmail)>> wrote:

Don't worry about overhead/bloat, in release builds asserts are gone.

And that's what I don't like about using straight assertions - the
behaviour changes radically between debug and release.

If someone has passed in a parameter which is invalid, why not just
throw the appropriate exception?

 

[Jon Skeet [C# MVP]]

Although one should use ArgumentExceptions to handle method arguments.
Assertion should be used only for theoretically impossible conditions in the
code that has nothing to do with external conditions like parameters, when
and how which methods are called or external ressources like files.
Agreed.

But yes - this is only theory. Often programmer prefer assertions because
they can't crash code in release mode as exceptions do and they do not
affect performance in release mode.

The thing is - why would I want a program to continue to operate as if
nothing had happened if I'm able to detect that something is wrong? For
instance, if I've detected that an age had ended up being negative, why
would I want to commit that to the database rather than throwing an
exception? The way I see it, throwing an exception as early as possible
when an error has been detected minimises how far that error can
propagate.

 

[cody]

But yes - this is only theory. Often programmer prefer assertions because

The thing is - why would I want a program to continue to operate as if
nothing had happened if I'm able to detect that something is wrong? For
instance, if I've detected that an age had ended up being negative, why
would I want to commit that to the database rather than throwing an
exception? The way I see it, throwing an exception as early as possible
when an error has been detected minimises how far that error can
propagate.

Yes, but sometimes something happens which you expected that it should not
happen but at the end is turns out to not to be wrong at all or at least it
doesn not affect the application in a negative way.
So it is good that assertions can give hints about these things but if they
happen to the end user nothing happens (although it wouldn't be a bad idea
to use logging here).

 

[Jon Skeet [C# MVP]]

Yes, but sometimes something happens which you expected that it should not
happen but at the end is turns out to not to be wrong at all or at least it
doesn not affect the application in a negative way.
So it is good that assertions can give hints about these things but if they
happen to the end user nothing happens (although it wouldn't be a bad idea
to use logging here).

Yes - I'd use logging rather than turning off the detection completely
in release mode. It's kinda handy to know whether it happens in the
real life.

I rarely see situations which are important enough to be informed about
in debug mode, but should be totally ignored in release mode.