![]() |
|
Think about Loose Coupling | |
PerlMonks |
comment on |
( #3333=superdoc: print w/replies, xml ) | Need Help?? |
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 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: 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. 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
|
|