Okay, I agree that they are only (very cursory) examples, but I'm really talking to the principle of what you are suggesting.
One of the smells I was thinking of is DRY (Don't Repeat Yourself) Principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
This is often mistaken/misinterpreted as a variation on OnceAndOnceOnly, but it is quite different (IMO). Using your example (whilst recognising it was only an example :):
my $first_foo = foo1 && foo2; my $second_foo = foo3 && bar1 && baz1; my $foo_is_ready = $first_foo || $second_foo;
And assuming (for the sake of discussion, and noting the absence of sigils) that foo1, foo2, foo3, bar1, baz1 are function/methods returning boolean values.
At the point of invokation, those methods are returning their result based upon the internal state of their objects. By temporarially storing the (composite) values of the methods into variables whilst deferring the decision based upon them, you create a window for opportunity for the internal state of one or more of those objects to change, through injected code, delay or some other mechanism.
You have also created new, named, compound states. If bar1 becomes redundant, then whatever well chosen compound name (symbolised by your $second_foo), that you chose to represent that compound state, is now wrong; and you have to not only remove the reference to bar1, but also rename $second_foo and all the subsequent places that reference it, so creating several potential maintanence problems along the way.
Whereas, leaving the compound state entirely within the compound statement:
if( foo1 && foo2 or foo3 && bar1 && bar2 ){ ... }
If laid out in a clear manner according to your preference or site standards, avoids all of these potential problems.
If the combined conditional states need further clarification, then comments are a better way:
if( foo1 && foo2 ## First foo or foo3 && bar1 && bar2 ## Or second foo ){ ... }
My own personal take on this is brevity == clarity. I find you rarely clarify anything when you add to to it's complexity, whether code or speech or writing (though as everyone here knows, the latter certainly isn't my forte).
Every now and again over the years I've encountered one of those people that comes to a meeting and listens to everyone else waffle on and then stands up and summaries all the issues in 2 or 3 sentences, usually of 10 short words or less. How I envy those people. They also tend to write reports 1/3rd the length of everyone elses and still say twice as much with 5 times the impact.
It's not about writing the shortest or the cleverist code. It's about doing just what needs to be done without adding anything that isn't needed.
"Only doing what needs to be done" is my take on Premature Generalisation, which is a little out of context here, but is still relevant if you consider your "used once states" in the same light as "used once functions" and "used once libraries". They do have their place and uses, but they should not be used without careful consideration.
In reply to Re^4: bloated 'if' formatting
by BrowserUk
in thread bloated 'if' formatting
by eff_i_g
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |