Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Seriously, I think the greater problem about identifiers rather than context. To stay with your example of "extract", that's a verb. When a method has a verb as a name, I expect it to do whatever the verb says. As the return value, I wouldn't (ever) expect a list, but instead some true value if the action has succeeded, and a false value if it hasn't.

    A method that returns something, should have a noun as its name, that describes what it returns. Even if it's something as simple and perhaps ambiguous as "fi

    • by btilly (5037) on 2008.06.23 22:27 (#63566) Journal

      You're right that good design starts with good naming. Unfortunately the idea of systemically basing your method and class names on grammatical notions is one that I was not exposed to until I read Perl Best Practices. Which did not immediately sink in because it was formulated in a very abstract manner and it took a while for the advice to sink in.

      Needless to say I wrote that module before this point.

      Still when you're facing a design mistake, it is worth thinking about all of the potential contributing factors. So you're right that a better naming strategy could have lead me to naturally name the method "values", which would have avoided the problem. And that is a good lesson. However it does not change the fact that there are other contributing factors to the example.

      In fact context provided another contributing factor. Given that pluralization is linguistically provided by context in Perl, there is a slight design pressure to pick names that don't change when you pluralize them. I've felt that pressure, and it is nothing more than the fact that it feels slightly wrong to be saying "many" and "one" at the same time in your code. However if you succumb to that pressure you'll almost always wind up making worse overall design decisions.

      With experience I no longer feel that, but I certainly did at one point, I expect that others do, and it is yet another way in which context can help trip people up.