in reply to Language features affect style

Note that Perl also has closures, which Java doesn't have. In some refactoring cases, you might want to use a closure instead of a method - it gives you some of the benefits private methods give you in Java.

But for me, there's a large difference between storing something in a temporary variable, and using a method. Assuming the temporary variable isn't tied, once you put a value in there, you get back the same value each and every time. With a method, that's less clear, certainly when seen from the caller's perspective. For instance: 

   my $v1 = $v2 + $v2;
   my $v3 = $self->m1 + $self->m1;

[download]
The first is equivalent to 2 * $v2, but it's not clear whether the latter is equivalent to 2 * $self->m1, until you know what m1 does.

And that's a language agnostic issue.

Replies are listed 'Best First'.
Re^2: Language features affect style
by tilly (Archbishop) on Jun 08, 2009 at 17:11 UTC
    When different languages can express different things, it makes sense to me that good coding style would be different. On methods that mutate data, it strikes me as extremely bad style for a method to mutate data under the hood and not make that clear in the name. If you assume that quality bar has been passed, the difference you're talking about disappears.

    I'd prefer to deal with code that has passed that quality bar. :-)

[reply]
      Yes, but a method name is usually only a handful of lines; you cannot expect you can deduce everything that happens from the name of a method. And what will be obvious for one, may not be clear for someone else.

      And code doesn't have to mutate data to return something else. Perl has iterators called 'keys' and 'each' whose name doesn't suggest at all it's modifying something.

[reply]
      I'd prefer to deal with code that has passed that quality bar. :-)

      Well, wouldn't we all? :-)

      However, I thought that one of the motivations for refactoring was making it easier to deal with code that has not passed the quality bar. Or knocked the quality bar off and left it lying in pieces on the floor...

      --
      use JAPH;
      print JAPH::asString();

[reply]
        This is true. However one of the goals of refactoring is to get quality up. So there is a bit of a chicken and egg thing going on. By assuming you're going to be a particular level of quality, you can make it easier to get to that level of quality. But in the meantime you're doing something that temporarily makes maintenance harder.

        Is that trade-off worthwhile? (My answer is, "sometimes". Apply judgment, hope it is good.)

[reply]

In Section Meditations