I think the precedence thing has been covered, but since DeMorgan's and "unless" got mentioned, a few thoughts about:
1. reducing Not's - this is a good idea!
2. DeMorgan's and using pictures instead of equations
3. Table driven approaches
I agree that factoring out negations improves readability.
If you get too many "not's" in there it can get confusing.
Without the "unless", this is another way:
sub done {
my $self = shift;
return !($self->foo or $self->bar);
}
Read as: I'm not done if I've got some foo or bar. To me this is easier than I'm done if I don't have this and I don't have that, but situations vary.
As far as converting between "AND's" and "OR's", I
always draw a picture, not a table or an equation -
just some little doodle on a piece of scratch paper.
When looking at (!$self->foo && !$self->bar),
I would draw an AND gate with two bubbles on the inputs,
interpreted as both low's on input means
a high output, then by inspection see that this means that any high
input yields a low output. Well, that is
a NOR gate. So I would draw an OR gate with a bubble on
the output. Then I would compare pictures and verify
that they really do the same thing.
So instead of working with some De Morgan's equation, work
with the picture. Ask a hardware guy to show you how they
do it. 30 minutes learning how to draw and interpret these
pictures (simple logic circuit diagrams) will save you
a lot of grief.
If things get too hairy to draw a simple picture, then
simplify things. Maybe you combine some things together in
an intermediate expression which is used in the following
statement, or something like that...
I guess I'm getting far afield, but there is another
technique when things get REALLY hairy, the table driven approach. This is
something to consider with "monster if's"... Depending upon the situation, it might or might not work out to be easier to understand and maintain.
|