in reply to Re: Language features affect style
in thread Language features affect style

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. :-)

Replies are listed 'Best First'.
Re^3: Language features affect style
by JavaFan (Canon) on Jun 08, 2009 at 17:25 UTC
    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.

Re^3: Language features affect style
by wol (Hermit) on Jun 09, 2009 at 17:16 UTC
    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();

      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.)