Re: Emacs Lisp coding style question

[Thorsten Jolitz]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> 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.

Ok

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

I often find functions much easier to understand if they use good
temporary variable names and the one-liner in the function body almost
reads like plain English. 

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

But in terms of uncompiled user-code - would the impact of the let
bindings here be worth thinking about performance?

> 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.

In this case I fully agree.

-- 
cheers,
Thorsten