3 ms·

Obviously a recommendation to have a high assertion density does not mean "shotgun-spraying assertions in the code". If your point is just that the rule could

Obviously a recommendation to have a high assertion density does not mean "shotgun-spraying assertions in the code". If your point is just that the rule could be applied mechanically and without thinking and that would be bad, then that's true, but it applies to everything, not just to the rule about assertions. Someone could apply the "keep functions definitions below 60 lines" rule in a perverse way, by splitting every long function definition at an arbitrary point in the first 60 lines and tail-calling a continuation. It doesn't mean the rule isn't a good one.

titzer 10y ago
In my experience that what's will happen in practice, especially when there is a specific metric attached. Doubly so once there is a mechanically enforced required amount of assertions. Wouldn't it be better if we could create programs that were correct by construction (and thus needed no assertions)?
- garethrees 10y ago
  I see — your experience suggests that rules inevitably get turned into thoughtlessly evaluated metrics that then get gamed. It is a shame when that happens, but when it does, it's not the fault of the rules, it's the fault of the organizational culture. The rules would still be valuable if you used them thoughtfully and with the aim of improving the reliability of the product, not gaming some management system.
  - efaref 10y ago
    I don't think they're intentionally gamed, it's just part of human nature. If you don't have to defend your assertions (because more assertions is presumed better, as per the rules), then people are liable to err on the side of putting more in that they need to. With the exception of assert(ptr != NULL) assertions, I think most of the ones I've hit have actually been completely duff, and with some thought could just be removed. I dread to think what would happen if I grepped the commit histories of all the projects I've worked on for "removed duff assert".
- wongarsu 10y ago
  >(and thus needed no assertions) Assertions are not meant to be needed. Any bug-free programm should behave exactly the same with and without assertions. On the other hand, in any sufficiently complex algorithm, asserting the pre- and postconditions generally helps readability, maintainablilty and correctness.

titzer 10y ago

In my experience that what's will happen in practice, especially when there is a specific metric attached. Doubly so once there is a mechanically enforced required amount of assertions. Wouldn't it be better if we could create programs that were correct by construction (and thus needed no assertions)?

garethrees 10y ago
I see — your experience suggests that rules inevitably get turned into thoughtlessly evaluated metrics that then get gamed. It is a shame when that happens, but when it does, it's not the fault of the rules, it's the fault of the organizational culture. The rules would still be valuable if you used them thoughtfully and with the aim of improving the reliability of the product, not gaming some management system.
- efaref 10y ago
  I don't think they're intentionally gamed, it's just part of human nature. If you don't have to defend your assertions (because more assertions is presumed better, as per the rules), then people are liable to err on the side of putting more in that they need to. With the exception of assert(ptr != NULL) assertions, I think most of the ones I've hit have actually been completely duff, and with some thought could just be removed. I dread to think what would happen if I grepped the commit histories of all the projects I've worked on for "removed duff assert".
wongarsu 10y ago
>(and thus needed no assertions) Assertions are not meant to be needed. Any bug-free programm should behave exactly the same with and without assertions. On the other hand, in any sufficiently complex algorithm, asserting the pre- and postconditions generally helps readability, maintainablilty and correctness.