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! 8  2044 
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
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.
"Jefffff" <A@B.COM> wrote in message
news:u5******** ******@TK2MSFTN GP09.phx.gbl... 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!
I was also a bit surprised by that statement (read it in Juval's excellent
"Programmin g .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.
"Jefffff" <A@B.COM> wrote in message
news:u5******** ******@TK2MSFTN GP09.phx.gbl... 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!
Although one should use ArgumentExcepti ons 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.
"Ward Bekker" <wa**@NospaaMeq uanimity.nl> schrieb im Newsbeitrag
news:e0******** **@news.cistron .nl... 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" <Marius Groenendijk (Hotmail)>> wrote:
<snip> 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 - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
cody <de********@gmx .de> wrote: Although one should use ArgumentExcepti ons 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.
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
>> 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.
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).
cody <de********@gmx .de> wrote: 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).
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.
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: P. Chalin |
last post by:
If you make use of assertions (e.g. assert statements) in your code, I
would like to invite you to participate in a 15 min survey on program
assertions. In this survey we seek your opinion concerning the issue
of errors/exceptions raised during assertion evaluation. The
questionnaire is available here:
https://www.dsrg.org/ASN_Survey/wnd.html
Thank-you in advance,
P.Chalin
|
by: Angel Tsankov |
last post by:
I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:
#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
|
by: Divick |
last post by:
Hi,
is it a nice idea to do assetion checks for method arguments ? I
am currently redesigning a piece of code. Now the problem is that there
are some assumptions for the method arguments that the code makes. It
is not checking the validity of the arguments everywhere because that
would lead to performance penalty. So I am think that at least
assertions will be able check the arguments at least for debug version
to verify the design. But...
|
by: douglass_davis |
last post by:
Say I would like to use assertions to make sure correct inputs are
given to a procedure. But, I want to do this in testing only, not in
production.
I saw Debug.Assert, which is nice, but does VB.NET have a feature where
you can turn off assertions on production code?
--
http://www.douglass.com
|
by: Matthew Wilson |
last post by:
Lately, I've been writing functions like this:
def f(a, b):
assert a in
assert b in
The point is that I'm checking the type and the values of the
parameters.
| | |
by: jeffc226 |
last post by:
This might be less of a design issue than a C++ language issue per se,
but I have a problem with assertions. I mean, they work, of course.
But there's something I'm uncomfortable with that's never been
explained to my satisfaction.
I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for...
|
by: Duncan Smith |
last post by:
Last week, I got reports back of errors in a patch I let someone try
out (release dll, but not from the build machine). Turns out it was
some Debug::Assert statements firing.
In umanaged code, I'd always understood that assertions were only
fired in debug builds and would compile down to NOPs in release builds
(for good reasons)
Now it looks as though I have to be careful to code assertions
conditionally?
|
by: Hugh Oxford |
last post by:
I am told that I should use assertions in my testing. The problem is,
because I test using a cut of live data, the data always changes. Has
anyone come up against this or have they abandoned assertions generally?
On a more general note, how does one reconcile a changing data set with
testing driven development?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
| | |
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
