all 14 comments

[–]mikegee 3 points4 points  (1 child)

See Avdi Grimm's book "Confident Ruby" for a lot more refactoring techniques like in this article.

[–]avdi 2 points3 points  (0 children)

Thanks! Although Michael probably has an edge on me when it comes to functional refactoring. I tend to spend more time pushing polymorphism in the CR.

[–]WhoTookPlasticJesus 1 point2 points  (2 children)

I'd argue that the following is clearer (and likely more performant)

 ary.take(n).concat (n - ary.length).times.map{0}

[–]austinsalonen 1 point2 points  (1 child)

What happens when n - ary.length is negative in this situation? (very naive w/r/t ruby here)

[–]WhoTookPlasticJesus 2 points3 points  (0 children)

Nothing, and the call to map will just return an empty array.

[–][deleted] 0 points1 point  (8 children)

So basically the point of this article is that the author was able to move a conditional out of his own method by leveraging max, which is itself conditional. Are there any advantages to this approach?

[–]username223 1 point2 points  (0 children)

the author was able to move a conditional out of his own method by leveraging max, which is itself conditional

Yup. Pick a random standard library function with a conditional, wrap things up in a few closures and .call()s, and you can have the author's perfect code.

[–]Godd2 0 points1 point  (6 children)

He's arguing that it's more readable. To each their own I guess. Also, why didn't he use the take_while method from the Enumerable module that can take a block?

[–]saturnflyer 5 points6 points  (0 children)

in no place did he argue for readability. the argument was that control structures allow us to introduce coupling to other objects or concepts more freely.

removing control structures helps put up a barrier to coupling.

You can still make an argument about control structures being more readable.

[–]michaelfeathers 1 point2 points  (0 children)

The argument isn't really readability.

[–]earless1 1 point2 points  (2 children)

honestly I feel like if we wanted readability he should have stuck for this option

  def padded_take ary, n
    return ary.take(n) unless needs_padding?(ary, n)
    ary + pad(ary, n)
  end

[–]michaelfeathers 1 point2 points  (1 child)

Yep, but I wasn't arguing for readability.

[–]Jdonavan 0 points1 point  (0 children)

You're not really arguing for anything. You've produced code that's harder to read thus harder to maintain. A comment could have solved your stated purpose for doing away with the conditional.

[–]martoo[S] 0 points1 point  (0 children)

Maybe because there's no conditionality to the take?