From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: Emacs Lisp coding style question Date: Wed, 02 Jul 2014 14:56:46 +0200 Organization: Informatimago Message-ID: <87mwcrudf5.fsf@kuiper.lan.informatimago.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1404306051 17795 80.91.229.3 (2 Jul 2014 13:00:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jul 2014 13:00:51 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jul 02 15:00:45 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X2K9Q-00015e-Sl for geh-help-gnu-emacs@m.gmane.org; Wed, 02 Jul 2014 15:00:40 +0200 Original-Received: from localhost ([::1]:52996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2K9Q-00054J-B0 for geh-help-gnu-emacs@m.gmane.org; Wed, 02 Jul 2014 09:00:40 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 84 Original-X-Trace: individual.net YTW/DN9KnjQWy0Rh8fMMfADPrJDeMqhHV+BpBBDEqpLMgXArdN Cancel-Lock: sha1:NDFmNWQ3YzY4NTAxZDY4YzQxZGQ3M2I4ZDZlYWY5MmIxMTI2YTc2MQ== sha1:5M24u2kKAVJnOr40UdNCznIOGMw= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:206230 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98501 Archived-At: Thorsten Jolitz 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 !"