Hi Leif, I also favor a slightly less verbose style. A function is an abstraction, > and you seem to be writing functions for very concrete steps.
yes, in the programming culture I am part of, method extraction is quite aggressive. Here is Martin Fowler on the subject (in Refactoring, Improving the Design of Existing Code <http://martinfowler.com/books/refactoring.html>): You should be much more aggressive about decomposing methods. A heuristic > we follow is that whenever we feel the need to comment something, we write > a method instead. > Such a method contains the code that was commented, but is *named after > the intention of the code rather than how it does it*. We may do this on > a group of lines or on as little as a single line of code. We do this even > if the method call is longer than the code it replaces, *provided the > method name explains the purpose of the code*. > *The key here is not method length but the semantic distance between what > the method does and how it does it.* I accept that that extraction of the following method is pretty aggressive: (defn reverse-every-row [sequence-of-sequences-of-chars] (map reverse sequence-of-sequences-of-chars)) What I am trying to find out is if this sort of practice is (or will ever be) used, or it use at least contemplated, by functional programmers. By the way, I guess if this was Scala then the overlong parameter name might be replaced with a something like 'rows : Seq[Seq[Char]]' Philip On Tuesday, 9 December 2014 05:06:22 UTC, Leif wrote: > > Hi, Philip. > > I had the same urge as David--I tried it out, glossing over any formal > rules. Here's what I came up with: > https://gist.github.com/leifp/ae37c3b6f1b497f13f1e > > In truth, I think David's solution is more readable and maintainable. But > I think "maintainability" is a pretty tricky concept: > > My code makes a seq of maps describing rows, and then turns them into > strings at the end. This is probably more work to understand than David's > solution. But is it less maintainable? Well, currently, the answer is > "yes," but what if I need to output a diamond in several different > formats? What if marketing wants each row to be a different color and > font? I would start to favor my solution in that case. My point is that > the difference between "maintainable" and "horrible" is evident, but the > difference between "maintainable" and "easily maintainable" depends on > predicting the future somewhat. > > I also favor a slightly less verbose style. A function is an abstraction, > and you seem to be writing functions for very concrete steps. I think you > have most of the correct abstractions for your solution method, you just > need to consolidate the more concrete steps. Something like: > > flip-bottom-up -> flip (or vertical- and horizontal-flip) > join-together-side-by-side -> beside > put-one-on-top-of-the-other -> stack (or ontop, or ...) > reverse-every-row -> (map reverse rows) ; very readable to clojure > programmers > > (let [top-right (create-top-right-quadrant-for letter) > right (stack top-right > (flip top-right)) > diamond (beside (map reverse (drop-first-col right)) right)] > (display diamond)) > > The broad takeaway is: if I write a function I only use once, I usually > just inline it. Unless of course I believe deep in my heart I'll have need > of it somewhere else soon :). > This is somewhat a matter of taste, and again, the requirements history > usually determines what gets abstracted into functions, and history can be > messy. :) > > Hope that helps, > Leif > > On Saturday, December 6, 2014 5:48:02 AM UTC-5, Philip Schwarz wrote: >> >> Hello, >> >> can you please review my first solution to the diamond kata [1] and tear >> it to bits: let me know all the ways in which YOU would improve the code. >> >> I am not so interested in a better algorithm for solving the kata. I am >> learning Clojure and what I want to know is what YOU would do to make the >> code more readable/understandable/maintainable, or just to make it follow >> Clojure idioms and/or conventions that YOU find effective, or to follow a >> coding style that YOU find more effective. >> >> Thanks, >> >> Philip >> >> [1] https://github.com/philipschwarz/diamond-problem-in-clojure >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
