Since this seemed to branch off from my topic, I thought I'd make a new thread here. Basically pointing out books that are bad or bad advice from books.
So, to start:
Quote:Original post by Hnefi Am I the only one who dislikes "Pragmatic programmer", finding it out of date and also containing some very bad advice (though also, admittedly, some very good advice)?
Anyway, it might not be technically language-independent, but let me recommend Deep C Secrets by van der Linden anyway. It's entertaining and educational.
Anyway, I'm dusting off the old book now, and checking through it here are the two main things I dislike - keep in mind that this means there's a whole lot of book which I don't dislike.
*The chapter "Assertive Programming", specifically the part about leaving assertions on. Assertions should never, ever be left in production code - and that has nothing to do with performance, which they discuss in the book. The real reason is that when a client does something that triggers an assertion (and I've been there - I've done trips to foreign countries because of it), it may take a long time to find out what the heck that assertion actually means.
Assertions are primitive and simple. They serve a useful function, but they are not a good way to terminate a program that is considered ready for commercial launch, because they demand too little information from the programmer. Unless working in a very tight embedded system (in which case assertions should be disabled in production builds anyway), use more verbose mechanics for terminal errors.
And the worst chapter of them all, the one that really got me to doubt the entire book for a while:
Chapter 30: Blackboards
In this chapter the authors recommend using blackboards. I'll assume everyone knows what this pattern is - and it's a horrible antipattern in any non-exotic large system. I should know; I've been subjected to it professionally. The problem with the blackboard is that it is indeed very black; anyone can put anything at any time on the blackboard, and you can never really be sure who, if anyone, will be interested in that information and when.
Most patterns allow you to easily follow the flow of information; not so with the blackboard. In a large system, which is where I've seen this pattern used, the blackboard can and will become a giant barrier that, once you run into it, forces you to start doing detective work to find out where the information is going. It's like the IPC barrier, but worse, because there is no real need for it. It's a horrible thing that should not be used unless there are very specific reasons for it or the project is very small. That the book argues in favour of blackboards so enthusiastically is its greatest failing, IMHO.
Anyway, beside that, I dislike that they haven't updated the version control discussion to include at least SVN in the latest edition, and I also disagree with their position on simple text editors plus fifteen other small tools being superior to IDE's, but that's mostly subjective.
Other than that, the book is full with good advice; it's mainly just the blackboard discussion I consider to be really bad, but it's bad enough to sink the entire book in my eyes. But to each his own, of course.
-------------Please rate this post if it was useful.
On retail assertions, I would agree for the most part -- its certainly not elegant -- however, I also see little point in letting a program continue erroneously after known and irrecoverable faults. In the embedded world its often better to halt and reboot in the face of unknown input rather than continuing on until the full force of such unexpected input is fully realized (perhaps continuing to dump radiation into someone's body, or some equally ill-favored result).
I've recently been mulling over the idea of assertions that aren't simply on-off, but have various levels of engagement and verbosity, one of the reasons being that a subset of "retail assertions" might be left in the released code, perhaps silently logging errors rather than causing a hard halt (after all, I'm just making games, not landing jets under auto-pilot [smile]).
... Anyways, hell -- Diakatana was released on PC with debug fully enabled, so if its good enough for John Romerro... [grin]
Quote:Original post by Ravyne On retail assertions, I would agree for the most part -- its certainly not elegant -- however, I also see little point in letting a program continue erroneously after known and irrecoverable faults. In the embedded world its often better to halt and reboot in the face of unknown input rather than continuing on until the full force of such unexpected input is fully realized (perhaps continuing to dump radiation into someone's body, or some equally ill-favored result).
I completely agree. For non-game software, I would say that its almost always desireable for the program to halt instead of continue to process incorrect data or produce incorrect results. A segfault, for instance, may not contain any information as to why, but at least you know right away that "something went wrong and the results probably cannot be trusted". Assertions are a step above that since they at least tell you where the error was detected (and how, eg fooPtr was null). Its more of a "produce errors with enough information" problem than a "detect errors" problem.
Quick exmaple (based on things I'm currently dealing with), when processing financial data, when assertions fail, the program may produce incorrect reports which in turn could lose the user a LOT of money - in this case I would prefer "assertion failed at foo.cpp line 123" and a prompt crash than something that tells them to sell all their stock or whatever you have. Its definitely not ideal - the user probably just wasted a lot of time working with something thats now been lost and theres very little information to help them diagnose the problem (and personally, I'd consider my work a failure if this was the primary means of error detection and recovery), but at least they aren't given false data with a false sense of security.
So in short, I completely agree that assertions are not a good tool for error handling, but I think having them (especially as a fallback error handling mechanism) is likely a better solution than not having them at all.
In games this may not be as important, since the player may not notice or care if the game continues with slightly incorrect data. It depends on the situation, I guess. Then again, a lot of games seem to be pretty sloppy and buggy works of programming...
Ravyne: issch: I believe you're missing the point when saying runtime assertions are desirable. The point is that assertions are not error reporting, they're ugly debugging tools that have no place popping up in retail releases. You should certainly still detect and report errors, but you should do so in a way that is useful to both the user and the developer. For example, write a user-intelligible error to a log file, save file/line info along with a stack trace and memory dump to a debug log, and then showing a dialog that helps the user get in touch with you and provide the information required for you to attempt to debug the product.
Code without error checking and handling (even when handling means quickly closing) is incorrect code, but there are far better error handling techniques than those typically provided by asserts.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
