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
In reply to Re: $bad_names eq $bad_design
by dpuu
in thread $bad_names eq $bad_design
by Ovid
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |