> On Wed, 16 Dec 2009 17:47:16 -0600, Bryan R Harris wrote:
>> Okay, here's one I struggle with often -- is one of these better than
>> the other?
>>
>> **************************************
>> A.
>> if ( isFlat($tire) ) { changeTire($tire); }
>>
>> B.
>> checkFlatAndChangeTireIfNecessary($tire);
>>
>> **************************************
>
> Ah, a recovering Java programmer :-)
I wish -- I've never done much more than perl and Visual basic I just pick
up bad habits easily. =)
> Seriously, the letsRunAsManyWordsAsPossibleTogether style bugs the heck
> out of me. The Perlish style (perldoc perlstyle) would be
>
> check_flat_and_change_tire_if_necessary( $tire )
For some reason I thought underscores were deprecated in subroutine names,
though I'm glad to be corrected.
> and I agree with Shawn's suggestion of object methods. But even if you
> don't use objects, you can clearly remove at least some redundancy:
>
> check_flat_and_change_if_necessary( $tire )
>
> Personally I would, all things being equal, probably write that as
>
> is_flat( $tire) and change_tire( $tire )
>
> putting the "tire" back in because a subroutine named just "change" is too
> vague. Oh, I see that's exactly what Shawn had. GMTA :-) There is also
>
> change_tire( $tire ) if is_flat( $tire );
>
> depending on what you think is more important, the changing or the
> checking. TIMTOWDI.
Mostly my question was about how to decide the extent of a subroutine's
functionality.
> The question you pose is one I see raised often in Java circles. It comes
> up rarely among Perl programmers. Possibly because we do not use nearly
> as many IDEs and automated refactoring tools. Neither will you find Perl
> programmers enamored of Hungarian notation, for instance. But remember
> that in Java these would be method calls anyway. Design Patterns in Perl
> look rather different. Many design patterns exist only to solve problems
> that don't exist in Perl (think typing).
>
> Java programmers are far more obsessed with learning correct ways of
> structuring methods. I find their discussions interesting but mostly
> academic. As long as my methods and subroutines are under a screen's
> length each and reusability is maximized (Don't Repeat Yourself), I'm
> happy. Whether the condition goes inside or outside the subroutine may
> depend on usage.
>
> The older I get, the shorter my methods get.
That's good advice. Great advice, actually.
In fact, I think what I'm coming to after all this discussion is this:
design your script so that your logic is as readable and clear as possible,
then your subroutines will just need to support that design.
Does that sound defensible?
Thanks.
- Bryan
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
