Too many asserts… yes a bad thing. Qualified: so long as they are replaced with something else. And, of course, “too many” is of course a value judgement.

Point 1 is like overcommenting. It seems like an assert here is not needed, as would be a comment like “#do something with bar”.

I find asserts useful for
a) Documenting assumptions and preconditions. For example, you could add an assert to show that you never expect to get a NULL. Otherwise, two years from now, someone is going to wonder whether ignoring NULL was on purpose or a bug.
b) Helping develop new code. For example, if loop over a list for an item that I know is in it, I might add an assert to make sure my index was within the bounds:

for (i = 0; wanted != items[i]; i++) {};
assert(i <= numberOf(items)); # wanted must be in my array of items, right?

Then the question becomes whether that assert should ever be removed.

Would you say that too many asserts is a bad thing?

I wrote a whole section about assertion checks in my Principles of Software article, http://wiki.freaks-unidos.net/weblogs/azul/principles-of-software#assertion-checks. I agree with most of the points you raise, indeed I said: “You should only disable your assertion checks if it is strictly necessary (for example, for performance reasons). I almost always run my software with assertion checks enabled.” I also wrote some thoughts about how slow it is acceptable to make your checks.

I’ll probably add a link to this article in that section. I’ll probably update it a bit to mention some of the ideas that you have here (I like the idea of a config switch that can enable or disable expensive tests).

One small suggestion: if one only skims through your article, it would at first seem to recommend that programmers don’t explicitly validate the state of their processes to protect against invalid programs. However, I think that couldn’t be further from your point: your point is actually that they should check it with better, “stronger” (so to say), mechanisms that Debug.assert. Perhaps you should rephrase the starting paragraph to say that you think that validating the state of your program is too important a task to use Debug.assert.

But there’s still a lot of C and C++ code out there that does not throw exceptions. In my co’s case, we had a library product where we wanted to avoid forcing users to use exception handling — at least at the time, a lot of people (rightly or wrongly) felt strongly about potential overhead, etc.

There are also times you want to be able to perform addl checks that are simply too expensive for a release build — for example, google on _GLIBCXX_DEBUG use with gcc.

Short version is that assertions can be very valuable, but should not be the only (or even the first) line of defense against bugs.