[Marble-devel] Some new suggested guidelines regarding usage of Q_ASSERT
Torsten Rahn
Torsten.Rahn at basyskom.de
Wed Aug 4 14:52:41 CEST 2010
I had seen some practices recently that I want to comment on:
Usage of Q_ASSERT
============
I personally have a bit of a dislike for Q_ASSERT. Why? Because it easily leads
to sloppy Trial&Error coding and bad code quality:
a) Either you KNOW for sure that a certain dangerous situation can NOT happen.
Then you usually wouldn't bother to do anything about it because you are 100%
sure that nothing can go wrong. Still writing a Q_ASSERT would feel stupid but
might be a good pick to play 500% safe during development.
b) Or you BELIEVE that a certain situation can not happen (because well, it
doesn't seem to be reasonable and without understanding the full code it still
probably won't happen since it didn't happen during testing. In that case please
DO NOT use Q_ASSERT!
Instead try to understand the code. If you succeed and if you then KNOW 100%
that the situation can not happen then proceed with a).
You are still unsure whether the dangerous situation could happen at some point?
Then please, please, please find a decent way out that will handle the case
without crashing! Once that is implemented you can still add a Q_ASSERT to get
notified about the "unintended" dangerous situation. But don't add it without a
"safe" fallback strategy.
I think that especially when it comes to parsing XML Q_ASSERTs should really get
avoided: When parsing XML code it's not reasonable at all to assume that a
certain kind of input can never happen. It's really bad if you put an assert
into that place because you realized that this might crash code under realistic
circumstances. Then usage of Q_ASSERT without finding a way to bail out safely
without crashing is really bad!
Torsten
--
Torsten Rahn
Senior Consultant
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-961 | Fax: -736|
torsten.rahn at basyskom.de | www.basyskom.de
Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrung: Eva Brucherseifer
More information about the Marble-devel
mailing list