> From: email@example.com > To: firstname.lastname@example.org > Date: Fri, 14 Dec 2007 20:27:30 -0500 > Subject: Re: [Lmuse-developer] sane programming > > If I may offer my opinion: > I agree that we don't gain much by using assert, and I avoid it > completely, because nothing pisses off a user more than having > the program stop, whether due to an assert, or some other > unpredicted cause.
The user should not be bothered with asserts, in addition to crash the program they can also decrease its performance, that's why I mentioned the flag -DNDEBUG...
> My style is that I keep the program running at all costs ! > Only when the program could not possibly continue, do I > quit with an assert or exit. It's called "mission critical". > My 'golden rule' is this: I check if a pointer is null, and if it is, > then I simply return from the function (with an error code, if allowed) > AND do a 'printf()' so I can see on the command line > that something went wrong. > But NEVER just quit the program. "Mission critical" means you plan > for such situations thoroughly, consistently, and gracefully throughout > the program.
Yeah I see what you mean, I actually started to code that way, putting a test rather than an assert so the program doesn't stop but soon I realized its awkward consequences, a bug occurs and you have no idea what is wrong because the unexpected behavior would make its way through layers and layers of code (assuming you don't handle code errors properly of course). Then the only way to locate the bug is to run a debugger and step each instruction one by one and carefully check at each step if it behaves correctly, using assert has the potential to alleviate that kind of wrong_behavior hunting.
> > Also, I would like to point out that if a function is passed a null pointer, > well OK, that's easy to check, but most of the time it will be passed > a BOGUS nonsense non-null pointer. You can't check such pointers. > In some cases, yes, you can check if it's a valid pointer if there is > a list of valid pointers somewhere and the pointer is not in the list. > For example in Muse there is a list of 'track pointers'. If a function is > passed a 'track' pointer, you can see if the pointer is in the list. > But beyond that, there's no way to check such pointers by themselves, > simply because attempting to de-reference them might crash the program. > This is why asserting for null pointers is rarely effective !
If a null pointer can be passed to a method without necessarily breaking the code's assumptions then assert should not be used, or should be used so that it captures what really breaks the assumptions like assert(!A || ptr);
> > All you need to do is start the program under a debugger, and the debugger > will tell you where the violation occurred. No valgrind etc. is needed.
Yes sure, my example from the start (with ptr) wasn't very good as using a debugger would rapidly locate the error anyway.
> > ***----------------------------------------------------------*** > While we are on the subject of programming style, I would like to alert > the programmers out there to watch out for a particular > Standard Template Library no-no: I call it the 'delete while iterating' bug: > In Muse I had to fix several places where someone iterated an STL 'map' > or 'list', and would conditionally delete items from the map or list, while > still iterating the map or list. This is a no-no! The iterator becomes > invalid after deleting an item, so the whole iteration has to be started > over again.
Yeah I see, I've suffered days of debugging on DeicsOnze because of that kind of careless coding attitude (that's when I started using STL without knowing much of what I was doing...).