[Box Backup-dev] [PATCH] Win32 merge [05] bbackupd

Martin Ebourne boxbackup-dev at fluffy.co.uk
Wed Aug 9 10:50:05 BST 2006


Chris Wilson <chris at qwirx.com> wrote:
> I actually find elseifs easier to read. The exact condition being
> tested is always at hand; there's no break/fallthrough nonsense that
> can easily confuse, and indentation is not a problem.

     if (state=3D=3DPending)
     {
         ...
     }
     else if (state=3DProcessing)
     {
         ...
     }

Can't happen with switch. Decent compilers warn these days =20
fortunately. But then decent compilers also warn if you switch an enum =20
value and don't handle all the valid values for it, which they can't =20
do with if/else. With long if/else its not clear that your intent is =20
to handle most or all the cases of a variable, rather than just a =20
disjoint set of conditions.

You're right about the fallthrough nonsense so that's why it should =20
always be avoided (except for the simple case of an empty fallthrough =20
so the case labels are together). I prefer to put a block around each =20
case handler with break after it to help make it clear that no =20
fallthrough is happening. The block also helps with local variable =20
scoping which is otherwise a mess in switch statements in C/C++.

Not sure how indentation is a problem. Just follow the rest of the code.

> Besides, I've done a lot of Perl coding, where switch doesn't exist,
> and Java, where it's effectively useless because there are no integer
> constants,

Ah yes: "You can write Fortran in any language"
Usually best to follow the languages idioms, whichever language you are usin=
g.

> so I'm out of the habit of using switch.

Perfectly fair point. ;)

> Whitespace fix. Please review.

Good to merge.

Cheers,

Martin.



More information about the Boxbackup-dev mailing list