I would like to second that notion. Having seperate builds for release and debug can hurt the stability of your product.
It is known that the development and production environments should be as similar as possible. This includes issues such as hardware, compiler and many more. This is done to ensure that what works in dev also works "in the field".
But using debug and release builds ruins those effords. That's because one of the basic things, which is the code that is being executed, is quite different.
Of course, some would say that release code is a lot faster than debug code. But is that gain in performence (which definitly exists) is worth it? Most desktop applications won't be slower in debug mode, IMHO.
That's why I don't like the assert macro (or the assert keyword in java). If you want code in the debug phase, you want it in production as well!
You do know that this (unlike the original code) works? That's because == in java compares references, and the two references are identical (that is, point to the same object).
Operator overloading is not a viable solution in java because, well, it just doesn't exist.
Besides, a line such as:
e = a.multiply(b.add(c)).divide(d)
Isn't going to win any "clean code" contests.
I would like to second that notion. Having seperate builds for release and debug can hurt the stability of your product. It is known that the development and production environments should be as similar as possible. This includes issues such as hardware, compiler and many more. This is done to ensure that what works in dev also works "in the field". But using debug and release builds ruins those effords. That's because one of the basic things, which is the code that is being executed, is quite different. Of course, some would say that release code is a lot faster than debug code. But is that gain in performence (which definitly exists) is worth it? Most desktop applications won't be slower in debug mode, IMHO. That's why I don't like the assert macro (or the assert keyword in java). If you want code in the debug phase, you want it in production as well!
You do know that this (unlike the original code) works? That's because == in java compares references, and the two references are identical (that is, point to the same object).
Operator overloading is not a viable solution in java because, well, it just doesn't exist. Besides, a line such as: e = a.multiply(b.add(c)).divide(d) Isn't going to win any "clean code" contests.