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  2015 
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**************@TK2MSFTNGP09.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
"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.
"Jefffff" <A@B.COM> wrote in message
news:u5**************@TK2MSFTNGP09.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 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.
"Ward Bekker" <wa**@NospaaMequanimity.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.com> 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 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.
--
Jon Skeet - <sk***@pobox.com> 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.com> 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...
|
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...
|
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...
|
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...
|
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...
|
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,...
|
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...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
