Myths about Debug.Assert!

Published Wed, Jan 19 2005 0:45 | William

Earlier tonight, I was giving a presentation on  and I interjected a sidebar - “Everyone here uses Debug.Assert, Right? ” because the code I was demonstrating was littered with Debug.Assert Statements. Why did I feel like asking this? Well, because to date,my use of Assertions has either pi33ed people off, been dismissed as a“useless waste of time”, or got me made fun of. The best response I got before this was merely telling me that they are unnecessary and not to use them. So I guess I was looking for validation of some sort because it'ssomething that i can't bring myself to give up. Nor is it something I have the least bit of desire to give up.My name isBill and I'm an AssertionAholic. I'm proud of that fact.If anything, I don't use them enough. So anyway, ONE person raised therehand when I asked if anyone used them. One hand. There were probably between 25-40 developers - all of which indicatedearlier that they were .NET developers. I got a few blank looks, but I also got abunch of eye rolling and smirks. One other person indicated he used to useAssertions but doesn't any more.

I guess I wouldn't have thought twice about it if I hadn't had such scorn in the past for using them.But it sunk intonight - I've never MET someone other than at product demos - who openly advocates using Assertions. Maybe I have, butI never heard anything said about it. I've never seen them in a product demo (although to be fair, I know Jeff Prosise uses them - demo code isn't the same stuff we write in production - Somewhere deep in my heart I know Jeff uses them). Here I am in aroom full of experienced .NET Developers, no doubt talented ones, and the best I got was one hand raised, one guy that used to use them, and apathy. IF YOU'VE NEVER HEARD OF ASSERTIONS - YOU ARE NOT THE SUBJECT OF MY RANT HERE! Unless of course upon learning about the virtue of assertions - yougo over to the dark side andbecome on of those thatridicule people who do. I was ignorant of them too, but “Where Once I saw darkness, now I see light”

Two men, who would follow off of a cliff - John Robbins and Paul Kimmel are responsible for helping me heal my evil ways. But this enlightenment, has brought me nothing but scorn. The problem is, John Robbinsused to jump out of airplanes when he was in the special forces, in the middle of the night from low altitude, and then go kick people's a33. Plus, he helped found http://www.wintellect.com/anddudes like Jeffery Richter, Dino and Francesco got his back, so no one messes with him. Paul, well, he's Paul Kimmel. There's also Dave Thielen, author of No Bugs, so when they use Assertions, no one says anything about it. But I'm just Bill - so the best I get is, well, a friendly ear on occassion - but most of the time I get laughed more than John Stewart does. Except they aren't laughing at him, and they are laughing harder at me. Or I get a polite but pretty stern rebuke. I'm not kidding here - seriously. On two occassions I've downright had my a33 chewed out becuase “MY” STUPID boxes keep popping up when they used one of the libraries I had written. If “MY” stupid boxes were popping up because I wrote the assertion incorrectly, that'd be fine - but in both cases it was a test for NULL and an object that was supposed to be instantiated but wasn't, failed my assertion. In short - my assertions DID exactly what I wanted them to - exactly. But I get yelled at about it.

John's Debugging Applications for Microsoft .NET and Microsoft Windows, which is a MUST READ, has cured me of more bad habits than I care to mention. Furthermore, he too was caught a lot of crap about using Assertions - although the manager that chewed him out sounds like so much of a dumb a33 that he gave John a lot to laugh back about. Paul quotes Dave on page 617 of His Book- “ASSERT THE WORLD”. But the part that really confuses me is that I've gotten crap from REALLY GOOD DEVELOPERS - DEVELOPERS WHO ARE UNIT TEST LOVERS - DEVELOPERS WHO HATE BUGS AND DO ANYTHING TO (except using assertions) TO ELIMINATE THEM.

How can this be? Well, I'll sum up the arguments I've heard against assertions - and CRUSH THEM. I couldn't convince them when I heard their arguments, but in this instance, it's not because I had the weaker argument. It's that they are WRONG, WRONG, WRONG. And I'm not trying to belittle any of the folks that I had these discussions with - on the contrary, I have the utmost of professional respect for each of them. But we're all wrong sometimes, and they are wrong on this one. The problem is that it's the ANTI-Assertion crowd that seems to be swaying popular opinion - at least the part that they are useless.

1) Assertions clutter code - True, but so do comments if you define stuff that isn't code as clutter, particularly XML Comments. Anyone want to argue that Comments are bad “Because they clutter code”? No. So how doesthis logically invalid argument apply here? Yes, if they cluttered code and added NO VALUE, or Less value than they provided, this argument would be valid - but it would have to be changed to “They clutter the code and provide no value”. But that would be preposterous. (Technically, I guess it would be that they cost morein clutter than the value they provided, but that's not the case either). Assertions not onlyADD Tons of value, they make code more CLEAR. Yes, I've been laughed at over this.This was the “silliest thing” someone ever heard. Oh really? Whatmakes my code easier to read, the fact that I assert SomeObject.Value gt; 100 or “Thismethod willcall the lt;see cref=”SomeObject”/gt; class' lt;igt;Whateverlt;/gt; method and return the sum of the two parameters? Now, what if I assert that both of the parameters are greater than 0? My three assertions will help a new developer understand what's going onin my method1,000 times more than lt;see cref=”DumbArgument”/gt;any day of the week.They only way they wouldn't is if the developer didn't know what an assertion was - but the learning curve on Assertions is 15 seconds, sothe cost of them learning is nothing - even if you think that they should never bother using them. YES, THEY ADD CLARITY. Not to mention that they will cause problems - forcing someone to look at them. If the logic changed, they will notify you ASAP because they'll blow up. All the/// In the world won't NOTIFY THE Developer that they are out of date.If I'm wrong here, please tell me where. So let's just take this right off the table becauseat best it's an ignorant argument - unless of course you are anti-comment - but in my case, none of the people I ran across were. And does anyone want to tell me that comments never get out of date and become more problematic than no comments - if they do? I've spent well over a week working on stuff in my career because of outdated comments that lead me down the wrong road. An assertino wouldn't do this. I'd immediately ask “Hey, I passed in 100 to this method and it blew up. but the spec says it can be anything from 0 to 1,000 - am I missing something?“ Then I get told, “No, 100 is legit, it's when it's over a 1,000 - the spec changed recently“ Then I add a 0 to the assertion and all is well.

2) They break code - True, but so does bad logic.They do however make sure you get the memo - bad code may or may not. Spare me the lectures on logging - because I'm pro logging. Seriously, just this morning I saw an Assertion and a Trace Logger playing together. They were having a lot of fun. No animosity whatsoever. If they break code, it's either because they are broken and should be fixed (and they are nice enough to inform you that there's aproblem) or your Code is.

3) We write Unit Tests so we don't need them. By that logic, I guess we shouldn't have airbags in cars, or have them activated because we wear seatbelts. Bugs suck. They cost money and inconvenience people. The more protection you have the better. AND YES, NEWSFLASH - you can use Both. Hey, what do you do in NUNIT? ASSERT? Wow, so it's cool in NUNIT - but not in code. Sure, if you write perfect unit tests all the time, and always update them ASAP, then you may have some tiny little point. But the developer that ALWAYS writes Perfect unit tests, covers all of his code, and always updates his Unit tests immediately - well, he/she lives right next to the Easter Bunny. Why are there so many code coverage tools if everyone's so f****** good at this?

But there's more. Unit tests are only as good as the logic that they are based on. I can write total sh1t code, and have all sorts of unit tests that don't bark. I shouldn't - if I write them right, but just about everyone I know makes mistakes occassionally. I make them every day. Let Ye Without an Imperfect Unit Test cast the first stone. Assertions are used in unit tests, but the DELIVERABLE is the code, not the Unit Tests. Unit Test should make the deliverable better - I'm all about Unit tests- but they aren't the deliverable. If all your unit tests pass but your code blows up - well, all that means is that you write sh1ttier unit tests than you do code. There are books written&about writing GOOD unit tests, entire blogs&about writing good unit tests - how can this be if it's so easy to write perfect ones?

Understand - I TOTALLY ADVOCATE UNIT TESTS - I just think that Assertions are cool too.

4)  Logging negates the need for those 'things' - Really.  Do Seatbelts negate the need for breaks?  Logging is done ex post facto.  Plus, you have to actually examine the log - oh - yeah, right, you can email.  Well, that would probably cause a situation more annoying than spam (emailing all code failures).  On the other hand, let's just assume for one second, that one developer in your organization is a d1ckhead - who hides his mistakes.  My Homie Phil can verify their existence, and I'm sure my homies can back me up - such people do exist.  So you're a responsible Anti-Assertion program lead and you have something bad happen, maybe a car wreck and injury, loved on sick or dying, something bad, which takes you out of the game for a week right before release.  And I'm joe d1ckhead that doesn't like acknowledging my problems.  While you're out - who's going to read those logs?  Hmmm?  Any mechanism you can come up with to negate my passive aggressive bs can be worked around.  If you email everyone - the email server could be down - people could filter them out because they get so many of them, people could automatically move them to a folder because of the volume (which they don't check) [Yeah, this never happens].

But screw pragmatism for a second - Logging/Tracing is ex post facto - I have to either check the log or have it pushed to me.  Period.  Ever remoted stuff?  The debugger can work pretty well most of the time, but it's not perfect.  Even if it was - I can ignore what just happened.  Maybe the testers don't have access to the server.  Who knows?  But one thing I do know is that having a BIG UGLY ASSERTION BOX RIGHT UP IN YOUR FACE, ONE THE DELIVERABLE - that's the least likely thing there is to go unnoticed.  And just like with unit tests, We can do BOTH!  And I'm all about doing both. 

BUGS ARE EXPENSIVE AND EMBARASSING.  And they set the tone for your customer relationships.  If the install and initial engagement is flawless, customers are more likely to attribute bugs to something on their end.  But let the install blow up in 20 different ways and take 8 hours longer than it should have - YOu'll never convince them - no matter what they do - that they are the cause of the problem.  But f*ck that - they paid you for something that worked.  Ok, a few bugs are tolerable - but I've used a bunch of stuff that I've never found a bug in.  And I bought version++ of damn near all of them.   But screw all that pride and customer focus stuff - let's take it to greed.  It takes 3 seconds tops for most assertions to fail.  It usually takes less than a few minutes to find out why and fix the problem.  F*ck it though, assume it takes a day.  It's still going to be cheaper than the ass kissing you're going to have to do  if they problem hides until it gets to the customer. 

HAVE I MADE MY POINT THOUGH?   Please, I totally welcome contrary opinions.  Please, bring them on.  If I'm wrong, fine.  But I'm not.  I promise, I'll address every argument anyone wants to present without calling John and telling him I live 4 miles from the BMW Plant, and I'll buy him a new BMW Bike if he Asserts your ass out of a window (Actually, John Robbins is probably one of the nicest people you'll run across - this is just me being silly) and then HALO jumps off the roof and shoots you before you hit the ground.  He probably could do it too.  

Comments

# TrackBack said on January 19, 2005 12:56 AM:

Debug.Assert is your friend 'mkay !!!

# William said on January 19, 2005 7:50 AM:

I use, effectively, debug.assert in the sense that my stateful objects incorporate self-inspect, which applies a series of assertions to state.

And I am quite familiar with MORONS who smirk at practices that they don't understand.

Joe Stud Coder is the type of Monkey Boy who just loves to seek out and destroy any practice which implies humility, and he loves to smirk like his hero George Bush.

Like Bush, he would NEVER admit failure to understand. When Gore seriously and responsibly described how to save MY frigging retirement, Bush smirked and called it "fuzzy math".

I've had it up to HERE with Joe Stud Coder. I've also had it up to HERE with Bush, but you knew that.

assert("Code Nazis must DIE")

Actually, Bill, you are in the grand tradition, for essential to understand how to formally or informally prove code correct OR predict its behavior is knowledge of "weakest precondition".

But Joe Stud Coder thrives on the schizophregenic BREAK in our society between THEORY and PRAXIS, one in which managers rave about things in the air and when you tell them how to get there, they call ya "academic".

"I don't want no normalized data base, I want a happy customer"

"Ok, whyncha give him a b*w j*b and stop bothering me? The customer is unhappy, dorkwad, because he can't form queries. He can't form queries because his moron brother in law put physician name in ten different fixed tables."

I mean, Krsna forbid there should be ANYTHING like a meaningful connection between anything at all.

There's a species of manager who doesn't want us to assert J*k s*t. He doesn't even want us to CODE. God forbid we should THINK. He's implicitly encouraging us to steal code from somebunny else.

It used to be that Labor went on strike. Today, Capital is on strike. It doesn't want Labor to risk a single extra line of code, whence the smirks from the sort of people who know the unwritten rules, and show their "smarts" by disrespecting great coders like you.

I know, I know...Communist propaganda. I'm a bad influence, aren't I. But without being a "Communist" I do believe we should have a shot at doing our stupid jobs to the best of our ability, and I am well aware that (whether by means of assert or my inspect) it is ALWAYS best to catch bugs at the earliest possible time.

If a variable violates assert, THEN you know (as a matter of analytic apriori goddamn logic) that the code is BROKEN at that point. But entirely too many programmers are such people-pleasing wonks that to them the code is broken only when the "user is unhappy".

Coding becomes in this regime an elaborate exercise in sucking up to the boss. Gee, if I wanted to do that, I'd get on the Apprentice. That blonde to Trump's right is HOT.

# William said on January 19, 2005 8:01 AM:

I love those little Human Proof squiggly codes!

The logic behind assert is simple.

IF the assert fails THEN the program is broken should be the operant guideline in designing a good assert().

By simple Logic 101, p->q means that ~q (your program runs correctly) implies that the assert will also run correctly, all the time.

Of course, IF the assert runs, the program is not KNOWN to be "correct".

Which causes morons who can't think logically (yet pull down 150,000 clams a year as PROGRAMMERS in Republican administrations) to conclude that assert is useless and to smirk, roll their eyes, grab their crotch and even make the whack off motion (with hands widely spaced to with utter falsehood imply they are not pencil dicks) in conferences.

All they want is truth's illusion.

Let me know, Bill, if I am over the top by referring to SOME programmers as pencil dicks. It is a metaphor and not meant in any way to offend the Fair Sex. We need in my opinion to return to full humanity and STOP pretending we are "above" the very idea of same out of fear of being thought Politically Incorrect.

# William said on January 19, 2005 8:21 AM:

The smirkers-at-assert (I will exercise Iron Self Control here and desist from referring to them excepts as Graphite Richards, or you know what: p. d.s) actually are using a folk sociology which is part of the problematic phenomenon they constitute.

Boy, that hurt.

What I mean is that folk programming sociology is constituted in the assertion as TECHNOLOGY a set of SOCIAL preconceptions which further comprise when taken in the large the precise phenomna the Graphite Rickies pretend to decry.

That hurt even more.

There is a serious and ongoing concern that programming is hard, and bug-prone. Much normative folklore has been devised mostly in the form of saws and rules of thumb which programmers bandy about often in a capillary spirit of Foucauldian one-up-manship where the transmit (from the local "guru's" irritating and tragic baritone complaints about your code to the autocthonic crotch grab in a conference) of the "technology" is actually a social mechanism.

We escape from this unconscious replication of what we KNOW to be a highly dysfunctional system by means of Kant's categorical imperative: "so act, that your action can be recommended as a universal moral law".

If everybunny used assert as intended we'd have...way better code. It's that simple. And it is as easy as "pie" for the compiler and runtime to turn off assert for a fully compiled and optimized module.

But the Graphite Richard crowd isn't concerned with the Categorical Imperative and instead are concerned about a continual one-up-manship which in the large becomes the obscene and murderous mess in Iraq, which was created by men interested in winning alone, just like Joe Stud Coders whose need is for you to acknowledge they are better than you.

At Princeton, I took a class from the philosopher and cognitive scientist Gil Harman and I assed him, Prof, idn't the whole point of computing just GETTING IT RIGHT? Can't there be a serious and responsible "critical theory of programming" based on one thing, and one thing alone?

That being, the TRUTH of a program is its correctness.

Plato reduced the worth of the State not to "efficiency" but to Justice.

Sure, we could say that a program that runs in nonpolynomial time WHEN A POLYNOMIAL SOLUTION EXISTS is just WRONG...not "inefficient".

assert("Bill Ryan knows his frigging job")
assert("Bill Ryan is a hell of a guy")
assert("Bill Ryan drove the snakes out of Ireland")
assert("Buy that man anither drink")

Or, as I used to sing to my kids in the car, "di jer Mither come from AAAAAhhrelannnn?"

One day, my younger son Peter said, in his simple and Gnomic way, "no".

# William said on January 19, 2005 9:13 AM:

reading this is just depressing. hearing about developers mock or dismiss any tool that will help them write more correct, safer, and bug-free code is just fucking pathetic. what's even worse is the outright arrogance that accompanies this behavior. it's no wonder that the norm for our industry is fucking spectacular failure.

on the other hand thanks...i'm in the middle of writing a new post, and this just validates what i'm writing about

# William said on January 19, 2005 9:19 AM:

THANK ALL OF YOU - I knew I couldn't be this out in left field ;-)

# William said on January 19, 2005 2:31 PM:

Depends on what you mean by using debug.assert. Since I don't often use the new squirrely languages the answer is no I don't often use debug.assert if you mean do I use the debug.assert concept then h3ll yes I do it all over in my code I use the Assert macro when writing console code and a variant of it when writing windowed code. It works the same way, it's compiled out in release mode but when testing it's invaluable to write that way. How the h3ll else would you be finding runtime logic bugs? Wait until the user calls you and says it's broke? Or hope you guessed every possible outcome for your functions and their data? Especially on the Windows OS where nearly all system level code is error based not exception based ASSERT everything!!! Especially in the design and hash out phase. In exception based code try catch everything. I prefer error based code personally because it's easier to debug and find problems that way for me. If you are an exception based coder more power to you just please don't ask me to maintain your code.

# William said on January 19, 2005 2:35 PM:

Debug.Assert will cause do nothing if your logic is true - if will throw up a warning box that let's you step into the debugger if it's false.

Debug.Assert(i > 10, "i Shouldn't ever be more than 10");

When you compile in Release mode though - it's left out.

Basically, the things I've heard are essentially that this is unnecessary if you do everything else right. My point is that while that 'may' be true - no one always does stuff right - and it's basically a really cheap supplemental insurance policy b/c you don't have to stop doing something else to use them.

# William said on January 19, 2005 2:58 PM:

I've been knee-deep in SalesLogix programming for more than I care to be and I've learned a lot of bad practices from it. Recently we've been given VBScript to do our scripting which includes a debugger which also gives me Debug.Assert commands yet I've never used them.

Pardon my ignorance but what exactly does debug.assert do? I thought it simply brings up a message when whatever you're checking against fails like "if 5<6 then pop up an annoying message box". That's kinda cool that it's left out of release mode by default which means it makes sense to have them at least in debugging mode. (They only bloat the debug code, not the release)

With SalesLogix I've had to resort to my favorite and most widely used form of debugging: MessageBox.

I dearly adore the messagebox debug, let me tell you. (Please shoot me now). I even went further to script my own DebugBox form that has a textbox on it so that I can paste whatever SQL statements or weird code back into Query Analyzer. A normal messagebox (or probably debug.assert too) leaves just text that you cannot copy which I contend is a huge waste of time. When dealing with databases and sql statements it pays dearly to be able to copy that stuff right from the error message and play with it directly.

Sadly SalesLogix has tainted my programming view. I did a little bit of debugger work with my Delphi code but I largely resorted to MessageBox debugs since it was easier than setting breakpoints and trying to figure out what in the hell was happening.

Personally I'd like to do things the easy way but in the case of a messagebox error I NEED to copy the damned thing 99/100 times so putting it in text form I CANNOT COPY is just plain stupid. There should be a debug.assert that uses a textbox so that you can copy the error message out into whatever you need. Since I deal with a ton of SQL queries, this is priceless to me. Then again in a typical debugger copying variables is probably easier than trying to copy the text off that messagebox.

Soon I shall embark on a "C# professional completion of an application for public consumption" quest in which I'll need things like unit tests, debug.assert, source control, continuous integration, and various other programming practices reserved for multi-person teams. It's going to be quite fun but learning this stuff on your own with little help can be daunting.

Thanks for the links for unit testing. I learn better from examples rather than some 500 page novel. All I need is a couple of templates to start off with that I can tweak/adjust/study and I can come out with exactly what I need without spending a ton of time reading through stuff I don't particularly care to know about. I know as a programmer I have a weird mentality but my skill is in reading and understanding code. That's why I adore the MS quick start stuff for .NET. Functional code that works teaches me far more than a book on the subject any day of the week.

# William said on January 19, 2005 3:06 PM:

I hate to nitpick and I'm probably being retarded here but this one is for Edward.

Do you know that you use somebunny and everybunny when you probably mean someBODY and everyBODY? I like being called a bunny, it's cute, but I knew someone who was home schooled and had problems knowing the correct spelling of words. She used to type egleast instead of atleast. The phonetics of the word were sounded so I understood what you both mean but some corporate type might read everybunny on your resume and have a fit.

Most likely it's just your clever spin on the conjunction of every and body but I wanted to make sure you weren't going through life with people ridiculing you behind your back, because half of the people that find that funny would never say a damned word about it.

Bill: I hate your comment CAPTCHA crap. I get Invalid Human Proof at least every comment because:
1) The font is weird. At least it's Verdana (or similar) so lower case l doesn't look like the number 1. This is a huge problem in Arial and Times I believe
2) The distortion of the text makes some things seem like others. 6 and G are probably very close and I can't tell because it seems like when I put in a 6 it's looking for something else.

While I'm all for non-spam comments using a system that makes the user work at it (usually more than once constantly) seems like a huge waste of time. I guess spammers won't want to take the 5 or so tries it took me to post comments to some of your posts. I just wish I didn't have to work so damned hard to post a comment (though I suppose it makes all of my comments worth a damn or I'd just give up)

# William said on January 19, 2005 3:21 PM:

Jeremy, Edward - the CAPTCHA is driving me nuts too. The whole site was getting slammed w/ spam so I belive Susan just inserted this for us.

However I'm doing a lot of reentering ;-)

# William said on January 19, 2005 3:39 PM:

I get a lot of invalid human proof too. I assure Mr. CAPTCHA I am indeed human please bless my comment and let it through.

....d@mmnit! second try

# William said on January 19, 2005 4:13 PM:

I'm a bit late two this discussion, but permit me to add my two Euro cents.

Assertions are a way of self-documenting the proper use of the API. I use them to test pre and post-conditions. For this reason, I let the testers on my team use debug builds. When an assertion fails, I am glad knowing it is a programming bug found early.

We had to go zero-bug bounce at a certain fixed date for a big project. Some team members complained loudly when they saw my assertions failing so much after making changes. They even suggested removing them. My response was to (threaten to) remove those developers instead. We made the deadline, and assertion helped to achieve it.

As a rule, I don't trust code that doesn't have assertions.

Bill, keep up the good work.

# William said on January 19, 2005 4:16 PM:

Roland - You are the Man! This is really good to hear!

# William said on January 19, 2005 10:20 PM:

Yes, I know the correct spelling of somebody, I instead do it to be disgustingly cute, like the stewardess who dots her Is with a heart.

# William said on October 27, 2005 7:54 AM:

What do you do when Debug.Assert is deemed as unessecary in your workplace?

# Aleksey Bykov said on October 6, 2006 3:45 PM:

too many bad words, watch your tongue

# Michael Freidgeim's Blog said on July 21, 2007 1:01 AM:

Debug.Assert vs Unit Testing Assert. class

Search

This Blog

Tags

Community

Archives

News

My other sites

Cool Stuff

Book Stuff

Security

ORM

Data Access

Funny Stuff

Compact Framework Stuff

Web Casts

My KnowledgeBase Articles

My MVP Profile

Design Patterns

Performance

Debugging

Remoting

My Fellow Authors

My Books

LINQ

Misc

Speech

Syndication

Email Notifications