[Kst] Policy on asserts, checks, and other defensive programming.
netterfield at astro.utoronto.ca
Wed Mar 16 18:23:30 CET 2005
Defensive progamming (memory checks, code skipping, etc) should be used iff:
-the thing being checked for could happen due to an action of the user or OS
(eg, the user resizes a plot too small, or allocates 1E12 samples in a
-a reasonable re-use of the code or reasonable changes elsewhere could
generate the event
-there is a reasonable strategy to cope with it.
(eg, don't draw or don't accept...)
-Memory checking by the UI at vector generation is good, because we know what
to do about it.
-We won't do memory checking when routinely creating a small fixed size item,
because linux currently doesn't let us do anything about it (cf, stack
-Checking for 0 size pixmaps is good, because on some window managers, with
some font sizes and icon sizes, the pixmap could end up zero size; and we
know of a clean way of handling it (don't draw).
This is always going to be a judgement call, so:
If, based on this policy, a developer decides to put one in **while working on
the code in question**, let them. (if you add one, please leave a brief
comment as to why it is there)
If, based on this policy, a developer decides to remove one **while working on
the code in question**, let them.
Actual documented bug fixes are always allowed, of course, but to avoid
sensless squabbling, please be specific about the behaviour you are changing
when you make the change...
(eg, prevents a crash when the user .... or speeds up redraws by ....)
Thoughts? Otherwise I will add it to devel docs.
More information about the Kst