Re: Emacs Lisp coding style question

[Pascal J. Bourguignon]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Hi List, 
>
> sometimes I wondered about the following coding style question, so I
> decided to do it in public:
>
> Often functions do a lot of work to gather some data and then do a
> rather simple action with the gathered data:
>
> #+begin_src emacs-lisp
>   (defun foo ()
>     (let* ((x (create-x))
>           (y (create-y))
>           (z (create-z x y))
>           (u (create-u z))
>           (v (create-v))
>           (w (create-w u v)))
>       (simple-action w)))
> #+end_src
>
> Thats the way I would do it, and I find it easy to write, read and
> understand. 
>
> But (without being able to give concrete examples right now) I noticed
> that advanced Lispers tend to call this 'C-style', consider the let
> bindings unnessesary since the local vars are only used once, and
> prefer this style:
>
> #+begin_src emacs-lisp
>   (defun foo ()
>     (simple-action
>      (create-w
>       (create-u
>        (create-z (create-x) (create-y)))
>       (create-v))))
> #+end_src
>
> This looks more 'lispy' and might have a slight performance
> advantage. But when the 'create-xyz' expressions grow in size the
> whole thing might start to look very complicated and it becomes hard to
> recognize that its just about `simple-action' with some gathered
> data. 
>
> What would be the recommended style for Emacs Lisp, or is this just a
> matter of taste?

Taste.

The later is generally better, since it avoids unnecessary (and
possibly misleading) temporary variable names.

Notice that both code might compile to the exact same binary, so there's
no efficiency advantage in either.

Also, if constructors names and signatures are well designed, the whole
subexpression:

      (w (u (z (x) (y))) (v))

can be considered more as data than as code (of course, there's no
difference between code and data, but I mean that when reading it, you
don't  read it as code, trying to understand a control flow and a data
flow, you just take it as a description of some structural data:

   (simple-action
     (vertically (square 10)
                 (circle 20 'red)
                 (horizontally (triangle 3 4 5 'green) (rectangle 20 10 
'blue))))

There's no need to try to understand the control flow and the data flow
in the simple-action argument expression: you just understand it
directly as a geometrical description.

If you introduced here variables, it would make it much worse.

(On the other hand, there are often ill-designed APIs that force you to
name subcomponents of such structures, to further build them; this is
bad).

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"