temp variables best practice

41 views
Skip to first unread message

Terrance Davis

unread,
Sep 12, 2009, 6:32:44 PM9/12/09
to clo...@googlegroups.com
Commonly, I break down complex lines of code into several easy to
follow simple lines of code. This results in many temp variables that
are not intended to be used anywhere else in the code. Sometimes I see
a method reusing common primitives and objects (like ints and
Strings), so to prevent verbosity (meaning many unnecessary variable
definitions), I define variables named something like 'tmpString' or
'tmpInt' with a local scope and reuse them locally.

This is all to prevent verbose hard to read code. I can read through
the simplified code ignoring variables with the visual tag of 'tmp'. I
also benefit from the simpler code that does not "chain" several
commands in one line.

What is the best practice in Clojure? How do I properly break down
chained commands? Am I completely missing the zen of FP? ;-)

Sean Devlin

unread,
Sep 12, 2009, 6:42:50 PM9/12/09
to Clojure
Could you post an example? It'd be easier to comment on it.

Terrance Davis

unread,
Sep 12, 2009, 7:23:38 PM9/12/09
to clo...@googlegroups.com
For instance, in Java ...

tmpString = JOptionPane.showInputDialog("What is your foobar?");
finalFoo = Double.parseDouble(tmpString);

instead of ...

finalFoo = Double.parseDouble(JOptionPane.showInputDialog("What is
your foobar?"));


I translate this into Clojure as something like ...

(def final-foo
(. Double parseDouble
(. javax.swing.JOptionPane showInputDialog "What is your foobar?")))


Obviously this a contrived example, and I didn't compile it to make
sure it works. Still, you can easily imagine more complex code having
many more levels of indentation.

How would I break up the Clojure version in a Clojure-esque manner?

Scott Moonen

unread,
Sep 12, 2009, 7:44:27 PM9/12/09
to clo...@googlegroups.com
Terrance, you could do something like this (loose on the syntax):

(def final-foo
  (let [tmpString (. javax.swing.JOptionPane showInputDialog "What is your foobar?")]
    (. Double parseDouble tmpString)))

Look at this comment for one example of a function written both ways: http://lojic.com/blog/2009/03/01/digest-tag-population-in-ruby/comment-page-1/#comment-1879

  -- Scott
--
http://scott.andstuff.org/  |  http://truthadorned.org/

Sean Devlin

unread,
Sep 12, 2009, 7:59:57 PM9/12/09
to Clojure
I like to use the comp operator to handle these situations

((comp
#(Double/parseDouble %)
#(javax.swing.JOptionPane/showInputDialog "What is your foobar")))

This is called "point free" style, the name comes from topology.

I find it easy to add/remove/reorder operations in this manner.
Instead of a continually indented list, the list grows straight down.
This also avoids use of local variables completely.

Other people have other styles, though.

Christophe Grand

unread,
Sep 13, 2009, 4:36:23 AM9/13/09
to clo...@googlegroups.com
Hi,

On Sun, Sep 13, 2009 at 1:23 AM, Terrance Davis <terranc...@gmail.com> wrote:

I translate this into Clojure as something like ...

(def final-foo
 (. Double parseDouble
   (. javax.swing.JOptionPane showInputDialog "What is your foobar?")))



While not directly related: try to not use the . (dot) operator. Use (Foo/staticMethod ...) or (.method obj ...) instead. (ditto for (new Foo ...) vs (Foo. ...))

(def final-foo
 (Double/parseDouble
   (javax.swing.JOptionPane/showInputDialog  "What is your foobar?")))

When you have nested calls on the first arg, you can flatten them using -> :
(def final-foo
 (-> (javax.swing.JOptionPane/showInputDialog  "What is your foobar?")
   Double/parseDouble))

You can even write:
(def final-foo
 (-> "What is your foobar?"
   javax.swing.JOptionPane/showInputDialog
   Double/parseDouble))

but I'm unsure we gain in readability this time.


-> proves also to be suseful when you are piling constructors:
(java.io.BufferedReader. (java.io.InputStreamReader. an-input-stream "UTF-8"))
can be rewritten:
(-> an-input-stream
  (java.io.InputStreamReader. "UTF-8")
  java.io.BufferedReader.)

HTH, Christophe
Reply all
Reply to author
Forward
0 new messages