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.