I'm reminded gigamonkey's footnote about when functions get too big: "A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head." [1]
There are many different styles for source code, but my experience with lisp suggests that variable indentation (as provided by emacs lisp-mode or clojure-mode) and parens-not-on-their-own-line makes for much more readable code. core.clj is a good example where the code is generally readable, but I shudder to think what it would be like to read the code for doseq or destructure if each closing parenthesis were on its own line. And, as for writing code, I couldn't live without paredit. To each their own, but let's not go down the route of saying "hey, you're code formatting style sucks, but I don't want to start a flame war" :). Cyrus 1. http://www.gigamonkeys.com/book/practical-a-simple-database.html On Aug 18, 2010, at 6:24 PM, wwmorgan wrote: > The Incanter example is confusing for the same reason that the > Leiningen example from the blog post is confusing, and I don't think > paren style matters at all. The functions have grown over time, > they're now too big, and they need to be refactored into several > smaller functions. The paren style is a red herring. core.clj is > readable because its functions are short. > > When your code makes you want to outdent, you can take this as a > signal that your function has gotten too big and needs to be > refactored. > > - Will Morgan > > On Aug 18, 4:36 pm, Greg <g...@kinostudios.com> wrote: >>> Now the question you're asking is, why don't lispers write >>> (MyFactory somearg >>> ) >>> which makes me cringe. >> >> That's not at all what's being suggested -- you'll find that both in the >> OP's code and in the link below, there are many locations where closing >> parenthesis are ended on the same line. >> >> Trailing parens are placed only for certain blocks that traditionally would >> define a "scope" in another language, and this is convenient for many >> reasons, including generic reasons not attached to any specific language. >> It's not about carrying over "much loved C style" to Lisp, but to make >> actual use of parenthesis for the purpose of clearly outlining the structure >> of your code. >> >> Again, the link goes much more into depth on this. >> >> Attached is a screenshot of some code from the wonderful Incanter library. I >> think it's a great illustration of how confusing stacking parenthesis can be >> (there are many functions in there that are like this). >> >> The readability issue occurs when there's a drop in several indentation >> levels after many lines. This is a problem regardless of what the >> indentation width is, but is certainly made worse by a small indentation >> width. >> >> - Greg >> >> Screen shot 2010-08-18 at 1.32.09 PM.png >> 48KViewDownload >> >> >> >> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: >> >>> A more serious answer is that when I code in Java I use the >>> brace-on-a-line kind of indentation. When I code in Lisp I >>> never write single-line parens of any kind. >> >>> I find that I think differently in each language. >> >>> My Java code is always a pile of declare-this, do-this, do-this, return >>> Thus I find that I'm delimiting the scope of my variables, marking my >>> control flow and branching logic, try/catch logic, class boundaries, etc. >> >>> My Lisp code mixes control flow and data structures in the same syntax. >>> Thus the idea that parens are some kind of control flow delimiter is >>> not particularly meaningful. >> >>> To see the alternative case, take a Java program, find every function call >>> such as: >>> MyFactory(somearg); >>> throw away the ';', and move the paren left to get: >>> (MyFactory somearg) >> >>> Now the question you're asking is, why don't lispers write >>> (MyFactory somearg >>> ) >>> which makes me cringe. >> >>> A second reason is that Lisp allows you to think things that Java >>> does not. Java has this imperative, object-oriented, hierarchical >>> style of writing. My lisp code sytle varies to fit the problem. >>> Sometimes it is imperative, sometimes functional, sometimes OO, >>> sometimes snobol-like pattern matching, sometimes class-based. >>> Occasionally I dynamically construct the code and execute it inline. >>> Or I use macros to create my own problem language and code in that. >>> And I create my data structures "on the fly" inline to the code. >> >>> Once you really internalize lisp there are no real constraints >>> on what you think or write. Thus there is no question of "bracing >>> style" that is meaningful. >> >>> The whole idea of "bracing style" is Java-think. Your language >>> choice has given you an OO-procedural mindset. So when you reach >>> for Lisp you want to see what you have come to expect. People who >>> work with bricks (Java) tend to wonder why they don't find bricks >>> among people who work with modelling clay (Lisp). The answer isn't >>> in the material, it is in your mindset. >> >>> Just by looking at lisp code I can tell what your native language >>> is. Fortran programmers simulate COMMON blocks, C programmers use >>> things as pointers, etc. "You can write Fortran in any language" >>> is a famous quote but "you can't write Lisp in any language". And >>> you can quote me on that. (But only in my obituary :-) ) >> >>> In fact, I think that this is going to be the hardest barrier >>> to the adoption of Clojure. "Real Java Programmers" are not going >>> to like the bracing style (or lack thereof) in Clojure. >> >>> Tim Daly >> >>> Greg wrote: >>>> It's almost purely community convention that has been adopted from Lisp. >> >>>> You may be interested in this link: >> >>>> http://gregslepak.posterous.com/on-lisps-readability >> >>>> There is much discussion about this topic there. >> >>>> Cheers, >>>> Greg >> >>>> On Aug 18, 2010, at 2:09 AM, michele wrote: >> >>>>> Wouldn't that make it easier to keep track of them. >> >>>>> Example: >> >>>>> (defn myfn-a [a b] >>>>> (if (zero? b) >>>>> a >>>>> (recur >>>>> (afn (bfn (...)) a) >>>>> (dec b)))) >> >>>>> (defn myfn-b [a b] >>>>> (if (zero? b) >>>>> a >>>>> (recur >>>>> (afn (bfn (...)) a) >>>>> (dec b) >>>>> ) >>>>> ) >>>>> ) >> >>>>> -- >>>>> 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 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 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 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
