in reply to On Quality

Broadly speaking, it sounds like you're talking about making sure your designs are logically/algorithmically correct. That's an honorable goal, but as Alan Perlis once said, "it's easier to write an incorrect program than understand a correct one."

Correctness is still something of a black art. Most of the research in actual machine-assisted verification seems to be happening in the area of Formal Methods, but nobody seems to have come up with a real killer app in that field, yet. Too many of the tools and notations out there use characters that don't exist on a normal keyboard. In that sense, they're kind of like APL.. they say you can write any program in the world as a one-liner in APL, and in six months nobody, including you, will be able to read it. ;-)

Joking aside, though, you'd probably do well to dig through the literature on correctness and add as many of the general techniques as possible to your bag of tricks. Three which I happen to like are:

  1. Always design for zero, one, or many inputs.
  2. Don't just assume an input's value will belong to a set of acceptable options, or fall within an acceptable range.
  3. Try not to let invalid input force branching. Always return a valid, usable result, even for invalid input.

Replies are listed 'Best First'.
Re^2: On Quality
by Aristotle (Chancellor) on Feb 23, 2006 at 08:48 UTC

    Always design for zero, one, or many inputs.

    Can you explain this in more detail? I think I have a rough intuition about what that statement means, but it’s too vague to be very revealing.

    Makeshifts last the longest.

[reply]

      It means, "avoid arbitrary limits", but the concreteness of "0, 1, or unlimited" is a useful benchmark.

      There are sometimes fundamental reasons for imposing limitations like "there can be at most one X per Y" (0 or 1), "there must always be exactly one X for each Y" (1), "no Y can ever have an X" (0). While limitations like "a Y can never have more than 5 Xs" are most often just arbitrary limits.

      Arbitrary limits very often come back to bite you. So it is good to have at least some motivation to do the extra (or perhaps just "different") work up-front to eliminate such arbitrary restrictions.

      So being at least suspicious of any "at most N" (for N > 1) restrictions is a good habit.

      Of course, sometimes 0 or 1 limits are actually arbitrary and (rarely) specific finite limits above 1 are not arbitrary. But the "0, 1, or unlimited" test is very useful.

      - tye        

[reply]

        Ah. That is a lot more concrete than the idea I had in mind, though on reflection, it is the same principle.

        This particular thing is something I’ve been doing instinctively – f.ex. one of the reasons to prefer dynamic, garbage-collected languages is that they tend to make this much easier, whereas in something like C, it’s generally a lot less work to pick arbitrary limits. But I hadn’t thought about it in such concrete terms, and I agree that the concreteness is useful.

        Thanks for the explanation.

        Makeshifts last the longest.

[reply]

In Section Meditations