Just a quick observation: at Google the Java practices guide says assert == "//". Assertions can be disabled, so you should never rely on it to crash if something is seriously wrong and you should never rely on side-effects of the assert expression.
On Wed, Aug 15, 2012 at 4:02 PM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Wed, Aug 15, 2012 at 10:46:06PM +0200, matic wrote: >> Sebb, Gilles and I would like to start a discussion [...] > ^^^^ > > It was not that "Sebb" who commented on MATH-845... ;-) > >> [...] >> >> @Gilles: sometimes assertion are a form of comments on steroid -> >> they will bark at you if you did not read them, and equally >> important: they are unambiguous. When I first write a method, it >> usually does not work right away. If it contains asserts, I usually >> get a clue of what's wrong, and if I don't, I try to write >> additional ones before tracking down the failure in a debug session. >> It is way faster, it forces me to understand better what I am coding >> (when I just follow a algorithm described in a paper, the typical >> situation for CM stuff) and the best of all: it will help anyone who >> later modify the code. >> -> in short, I see assertions as an invaluable tool to help >> developers, not just something to check input parameters in private >> methods. For this reason, I would support the following policy: >> 1. Use asserts as much as you like, but they are by no mean a >> substitute to runtime checks (code that throws "MathInternalError") >> for input parameters of public methods. >> 2. Asserts must be enabled in all unit tests > > I don't deny that assertions can help you while developing, but the > algorithms in the CM library should not be construed as a "work in > progress". To be sure, quite a few areas definitely need all kinds of > improvements, but what I mean is that when something is checked in, it > should be working as expected (bugs notwithstanding) by the developer. That > means: "assert" statements will not be triggered. Unit tests should be > provided to ensure that everything (ideally) behaves as expected. > > I understand that you did not mean to replace runtime check with assertions > but I'm a little afraid that "assert" will be considered enough (or better > than comments), such that the amount of comments will be reduced (while the > opposite should happen). > Moreover, "assert" generally checks "obvious" mistakes, which will happen > during development but are much less likely to occur when the finished code > is being called (I think). Once you start sprinkling "assert" statements in > a library like CM, it can quickly become littered with hundreds of them (in > fact there would probably be more "assert" than there are precondition > checks). I wondered how more readable that will make the code and for what > added value. > I understand that the readability would suffer (and even more) by > introducing logging statements all over the place, but at least that would > provide the benefit that one could be able to trace a bug to its root cause. > [I'm saying this because I recently wished I had logging inside a CM > alogrithm, while "assert" wouldn't have helped.] > > > Best regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
