in reply to $bad_names eq $bad_design
I agree with the premise: but sometimes the problem isn't actually the design: its that you're trying to abstract something too far.
Consider your example:
which became# if we have an expense account and the amount is too large if (4223 == $acct and $amount >= 100) {
If I don't understand the system, then the second form is probably no better than the first. Although the named function is explicit, I still need to look at the definition because I don't know what an excessive_expense_account is. A better name might help (e.g. "expense_account_is_over_limit(...)"): but, as a maintenance programmer, I'd prefer to see:if ( excessive_expense_account($acct,$amount) ) {
This contains meaningful names, which helps me to read the code: plus it has detail, which is needed for me to truely grok it. When we abstract out the detail, even to a meaningful name, then we circumvent the human brain's chunking mechanism. We only have a meaningful name: not the detail that enables the brain to see the patterns.if ( $acct->is_expense_account && $amount > EXPENSE_LIMIT) {
The summary: don't abstract too far. If you have difficulty finding a name, then by all means use this as a flag to re-examine the design. But if the design look good, then consider leaving it alone: don't force details into function names. Polysynthetic identifier names are all very well, but grammar exists for a reason: to aid comprehension.
--Dave
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Re: $bad_names eq $bad_design
by rir (Vicar) on Dec 20, 2002 at 22:02 UTC | |
by dpuu (Chaplain) on Dec 20, 2002 at 23:28 UTC |
In Section
Meditations