On 22 September 2016 at 03:34, Michael Kjellman < mkjell...@internalcircle.com> wrote:
> They can both live in harmony and they both serve a purpose. Thanks for writing that Michael. I'm a big fan of assert statements and have over the years seen them add value and stability to projects *when* used correctly, so I'm keen to add to your statement in hope it applies to the C* codebase and to see if it's basically a shared view here. The problem with assert statements is that they're not used correctly in combination with hard conditional checks and unit testing. Projects are partially to blame for this when they don't document this, especially when they contain plenty of (legacy) code doing it the wrong way. So if the following makes sense, I propose we add to C* coding style something along these lines… - Always use Guava pre-conditions for argument checking and required validity checks. - Use assert statements for fail-early (or fail-with-clarity) checks. - Assert checks may be expensive while guava pre-conditions should not be. - Use both guava pre-conditions and asserts to improve a method's documentation (self-checking documentation doesn't become outdated). - Neither Guava pre-conditions nor assert statements should be an excuse for, or promote the lack of, code that isn't easily unit testable. Assert statements can help simplify unit test methods, by moving validity checks into the codebase, but must not be seen as a replacement for unit tests. At the same time assert statements can be used to reduce test pollution. Unit tests should test the existing APIs, not create additional APIs that have no purpose but for the tests. - Every codebase should have a unit test that fails if java asserts are not enabled. A bit more info of some of these points… *Always use Guava pre-conditions for argument checking and required validity checks* As Ed writes: > https://docs.oracle.com/javase/8/docs/technotes/guides/ language/assert.html > > Do *not* use assertions for argument checking in public methods. > Do *not* use assertions to do any work that your application requires for correct operation. This is a pretty solid rule to apply as to when to rule guava pre-conditions instead of java asserts. *Assert statements may be expensive while guava pre-conditions should not be.* This illustrates that disabling assertions can in production environments be of performance benefit. The notice that we should always enable assertions in production environments I can't yet agree with because of this. But definitely the performance claim should not be put out there. *Every codebase should have a unit test that fails if java asserts are not enabled.* If the code has assert statements then unit testing (and all other testing but performance testing) needs to ensure assertions are enabled. And because of this, I politely disagree with Dave Brosius' statement: > As an aside, C* for some reason heavily uses asserts in unit tests, which adds to the "can't see the forest for the trees" problem. I see no reason for that. Not because you should use assert statements in unit tests, you shouldn't, but because it must not matter. ~mck
