I wouldn't say that. It depends on what the function is doing, and to some extent on your philosophy. Some would suggest breaking functions into very small functions, though I'd mostly only break out separate functions if they are separately useful. If naming the intermediates isn't very useful for making the purpose of the code clearer, but writing the function body as (last-step (late-step (middle-step something (early-step arg1 arg3)) arg5) arg2 arg4) is going to be a confusing mess, the threading macros may be a fine alternative.
That said, most of my functions are either: * Short; * Long let bindings, short body; * Mid-size; * Mostly a (loop ...); or * Mostly a body that mutates stuff, likely a big (doto ...) or (dosync ...) or a series of send-off, swap!, etc. The last and some of the others being not pure, so usually at the periphery of the system. Controller, DAL, or other such role. In a few cases I'm using mutable Java objects but in a somewhat functional way -- for example, one body of code works extensively with graphics processing, and the functions tend to all have a (let [bi (BufferedImage. ...) g (.getGraphics bi) ...] (doto g ...)) type of structure. They don't mutate their BufferedImage arguments, instead constructing a new instance and returning that. Some also throw around arrays, for performance reasons, and though these are technically mutable they also follow a "builder pattern" and a "pretend it's immutable pattern" where functions don't mutate their array arguments and only use aset to initially create array-valued returned results, or to work with intermediaries that do not escape the function at all. This avoids headaches with aliasing and concurrent mutation (as once either a BI or an array is visible outside its creation code it's not being mutated any more by any code) while gaining the performance and interop benefits of using Java's mutable types (e.g. JComboBox constructor takes array of items, JComboBox object is mutable, eschewing JComboBox is a lot more work than using it if you need a GUI with a combo box widget in it, so use arrays and JComboBoxes but use them in as sanitary a manner as you can; arrays of primitives are more compact and faster when doing certain numeric stuff; BufferedImage allows to use ImageIO instead of having to write one's own PNG en/decoder, one's own JPEG en/decoder, and allows to use Graphics2D instead of having to write one's own line, filled-box, circle, etc. routines). On Thu, Sep 5, 2013 at 3:39 PM, Kuba Roth <kuba.r...@gmail.com> wrote: > Thanks, very interesting point. It's a shame this is not available in the > clojure docs - very useful for newcomers as me. > Is it fair to say that let bindings is good/recomended to put all the > code and the main body is used primarily for returning results of the > function? > > Cheers, > Kuba > > -- > -- > 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/groups/opt_out. > -- -- 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/groups/opt_out.
