Myths about Debug.Assert!

Debug.Assert vs Unit Testing Assert. class

Michael Freidgeim's Blog — Sat, 21 Jul 2007 06:01:18 GMT

Debug.Assert vs Unit Testing Assert. class

re: Myths about Debug.Assert!

Aleksey Bykov — Fri, 06 Oct 2006 20:45:08 GMT

too many bad words, watch your tongue

re: Myths about Debug.Assert!

William — Thu, 27 Oct 2005 12:54:00 GMT

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

re: Myths about Debug.Assert!

William — Thu, 20 Jan 2005 04:20:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 22:16:00 GMT

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

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 22:13:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 21:39:00 GMT

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

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 21:21:00 GMT

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 ;-)

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 21:06:00 GMT

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)

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 20:58:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 20:35:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 20:31:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 15:19:00 GMT

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

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 15:13:00 GMT

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

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 14:21:00 GMT

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".

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 14:01:00 GMT

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.

re: Myths about Debug.Assert!

William — Wed, 19 Jan 2005 13:50:00 GMT

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.

Debug.Assert is your friend 'mkay !!!

TrackBack — Wed, 19 Jan 2005 06:56:00 GMT

Debug.Assert is your friend 'mkay !!!