Arguing by-example vs. by-principle
You can argue by providing examples supporting your case. Alternatively, you can argue by appealing to more general principles.
For example, in arguing that "exposing public fields is bad," you could say:
By-principle: "It breaks abstraction and encapsulation."
By-example: "This untrusted plugin could set field m_foo to value 4 and cause a null-reference exception on line 16 of file widget.cs".
| By example | By principle | |
| When it's good | Sometimes an example / counter-example can clearly illustrate a problem in an undeniable way. (example) | Can rapidly prune the decision tree and avoid wasting time in overly specific discussions that would ultimately lead to a dead-end. |
| Abstraction level | low - uses specific data points | high - uses generalizations |
| When it's bad | This puts a burden on coming up with the "killer example", which you may not be able to do until it's too late. You can waste a lot of time trying to come up with specific examples. The inability to come up with a specific killer example can lead to a false sense of security. (Just because I can't find a bug in your code does not mean it's bug-free.) | Principles may be more subjective and may be more complicated to process. Principles can be easily misapplied. (eg, "My principle is that our code should never crash; therefore I'm going to explicitly put null checks before every pointer access"). |
| Myers-Briggs of target audience | S (sensory) | N (intuitive) |
Comments
- Anonymous
March 29, 2008
Well, it's actually a mathematical principle: testing a solution with various values gives you a certain degree of confidence: it's not wrong...yet. If the domain to test against is infinite, it only gives some reassurance. Proving, on the other hand, is, well, proof that, as long as it is correct, usually covers the whole domain in "one hit"