Two of the refactorings are Extract Method and Introduce Explaining Variable. Both refactorings are appropriate when you have a complicated expression whose purpose is not obvious, and are particularly useful if said expression is calculated more than once. In Extract Method you encapsulate the computation into a method that returns the computation. In Introduce Explaining Variable you perform the computation once, and assign the result to a well-named temporary variable.
So far this is language agnostic. You can use either approach in either Java or Perl.
The interesting difference is that Fowler advocates using Extract Method in Java, while I'd be much more inclined to Introduce Explaining Variable in Perl.
His reasoning is straightforward. In general it is no harder to extract methods than to introduce temporary variables. The performance difference is generally negligible. And once you've extracted a method, it is then available to be used anywhere you want in the object. Which makes it easier to apply other refactorings that may break a long function into many smaller ones.
My reasoning is also straightforward. Writing methods means writing more boilerplate. Typos in method names are not caught by strict.pm, while typos in variable names are. Furthermore I worry about accidentally choosing clashing names. The wider visibility of a method makes mistakes more likely than with a temp.
All of my reasons are a bigger issue in Perl than Java. Java's syntax for methods has less boilerplate than Perl's. Java's type system lets typos in method names be caught. He addresses the method clashing issue by using private methods, which Perl doesn't have. (Warning for fans of other dynamic languages, private methods in Java are different than, say, what Ruby calls private methods.)
This lead me to accept his reasoning for his Java style, even though in Perl I'll continue to choose differently. As a result when faced with completely equivalent code in the two languages and the choice of completely equivalent straightforward modifications, in many cases I would choose differently. My sense of good programming style is therefore not language agnostic. The difference may seem minor, but it surprised me that it exists at all.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Language features affect style
by JavaFan (Canon) on Jun 08, 2009 at 07:59 UTC | |
by tilly (Archbishop) on Jun 08, 2009 at 17:11 UTC | |
by JavaFan (Canon) on Jun 08, 2009 at 17:25 UTC | |
by wol (Hermit) on Jun 09, 2009 at 17:16 UTC | |
by tilly (Archbishop) on Jun 09, 2009 at 17:30 UTC | |
Re: Language features affect style
by Arunbear (Prior) on Jun 08, 2009 at 12:36 UTC | |
by TimToady (Parson) on Jun 08, 2009 at 15:17 UTC | |
by John M. Dlugosz (Monsignor) on Jun 09, 2009 at 19:13 UTC | |
by TimToady (Parson) on Jun 09, 2009 at 23:15 UTC | |
by John M. Dlugosz (Monsignor) on Jun 10, 2009 at 17:01 UTC | |
| |
by Anonymous Monk on Jun 08, 2009 at 15:30 UTC | |
by holli (Abbot) on Jun 10, 2009 at 06:51 UTC | |
Re: Language features affect style
by tsee (Curate) on Jun 10, 2009 at 15:13 UTC | |
by tilly (Archbishop) on Jun 10, 2009 at 15:20 UTC |