[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