On 3/19/21 2:51 PM, Andrii Nakryiko wrote:
It's a matter of taste, I suppose. I'd probably disagree with you on
the readability of those verifier parts ;) So it's up to you, of
course, but for me this code pattern:
for (...) {
if (A) {
handleA;
} else if (B) {
handleB;
} else {
return -EINVAL;
}
}
is much harder to follow than more linear (imo)
for (...) {
if (A) {
handleA;
continue;
}
if (!B)
return -EINVAL;
handleB;
}
especially if handleA and handleB are quite long and complicated.
Because I have to jump back and forth to validate that C is not
allowed/handled later, and that there is no common subsequent logic
for both A and B (or even C). In the latter code pattern there are
clear "only A" and "only B" logic and it's quite obvious that no C is
allowed/handled.
my .02. I like the former (Martin's case) much better than the later.
We had few patterns like the later in the past and had to turn them
into the former because "case C" appeared.
In other words:
if (A)
else if (B)
else
return
is much easier to extend for C and later convert to 'switch' with 'D':
less code churn, easier to refactor.
