On 12/26/2009 00:47, James McKenzie wrote:
Nikolay Sivov wrote:
Why? There's no default case, treat is as 'if () {} else if () {} etc.'.
It's the same thing to have explicit initializers for all local
variables even if I don't use it before
set some value. It's a pollution, especially if used to silence
analyzer warnings.
Nikolay:
Things can and do go 'wrong'. For instance, you build on Linux, I build
on a Mac. Sometimes the ported programs from UNIX can and will do
'strange' things. If you don't have a method to know that there is an
error, then you go about blaming Wine when it is a poor program port.
That's a Mac build environment then. If there's no real problem now,
there's no point to add such
workarounds, if it is then a compiler should be fixed.
Also, it is good programming practice to account for the situations you
don't expect to encounter and to initialize variables that you will be
using. This is not a 'just in case' thing, it can help when program
errors occur to see where in the code an expected value did or did not
happen.
It also hides things sometimes and adds noops.
I know, it looks like pollution, but when code goes wrong, and it will,
this makes troubleshooting much easier.
It will go wrong only due a build problem or something like that, it
such case you can't trust a line.
I know this from running
Quality Assurance testing for many years and coding myself. My
programming instructor deducted grade points for failing to handle error
and other unexpected conditions.
Ok, in theory yes, but I'm speaking about a particular piece.
James McKenzie
Anyway, my point is that code in subject is clear and can't cause
problems patch tries to predict -
it's the same condition used twice.
I really have nothing to add here, let's see Alexandre's opinion.