From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: code review request for saveplace with dired buffer Date: Fri, 7 Jun 2013 22:09:39 -0700 (PDT) Message-ID: <7cec361d-9286-42e1-94eb-379bba6620ff@default> References: <87ppvy4e0m.fsf@kanis.fr> <8761xpvrma.fsf@kwarm.red-bean.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1370668192 30755 80.91.229.3 (8 Jun 2013 05:09:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Jun 2013 05:09:52 +0000 (UTC) Cc: Ivan Kanis , Stefan Monnier , Emacs Development List To: Glenn Morris , Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 08 07:09:50 2013 Return-path: Envelope-to: ged-emacs-devel@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 1UlBPR-0003tl-Vf for ged-emacs-devel@m.gmane.org; Sat, 08 Jun 2013 07:09:50 +0200 Original-Received: from localhost ([::1]:59613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlBPR-0008Jc-AP for ged-emacs-devel@m.gmane.org; Sat, 08 Jun 2013 01:09:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlBPN-0008JW-79 for emacs-devel@gnu.org; Sat, 08 Jun 2013 01:09:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UlBPM-0006Ht-2p for emacs-devel@gnu.org; Sat, 08 Jun 2013 01:09:45 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlBPL-0006Hp-Rp; Sat, 08 Jun 2013 01:09:44 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5859dJv024570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jun 2013 05:09:40 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5859eoW004575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 05:09:40 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5859dnA004564; Sat, 8 Jun 2013 05:09:40 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160260 Archived-At: I mentioned: > A Common Lisp convention is to use `when' and `unless' when the > return value is not important. It communicates to a (human) reader > that the body is for side effects only. >=20 > I, for one, use this same convention with Emacs Lisp. I consider > code that depends on the return value of `when' or `unless' to be > bad style (misleading). Some will disagree, no doubt. I was pretty sure that this style guidance was even called out in the Common Lisp spec/manual, but I hadn't bothered to look it up again (and it's been decades since I read it). And so it is. Here is what "Common Lisp The Language 2nd Ed." says: "As a matter of style, `when' is normally used to conditionally produce some side effects, and the value of the `when' form is normally not used. If the value is relevant, then it may be stylistically more appropriate to use `and' or `if'." IMO, it's too bad that Emacs Dev does not appreciate & adopt such a convention, as it helps users by informally communicating programmer intent. Yes, of course any such informal communication can mislead if applied incorrectly, just as can an incorrect comment. Still, it makes sense. To add to this, I'll mention that if the return value is important then I also tend to use `and' instead of `if' with no else clause. E.g.: (use-value (and some-conditon return-value)) vs (use-value (if some-condition return-value)) I don't claim this second style guideline is a Common Lisp convention. But as a consequence of these two rules, if you see an `if' in my code then you can expect one or more else clauses. If you find an `if' with no else clause then it probably does not reflect what I intended - what I thought I coded (likely a bug somewhere). A third rule I use: I generally avoid using `if' with a literal `nil' as result. The condition can be negated to get rid of the `nil', which would, by the second rule, be replaced by `and'. E.g.: (use-value (and condition return-val)) vs (use-value (if condition return-val)) ; 2nd rule or (use-value (if condition return-val nil) ; 3rd rule or (use-value (if (not condition) nil return-val)) ; 3rd rule An exception to the 3rd rule can be when `nil' is used as the empty list. But in that case I (try to remember to) write it as `()', not `nil'. E.g.: (use-list (if condition () other-list)) I don't always do that, though - sometimes even for a list I use (and (not condition) other-list). Depends how much attention I want to draw to the empty-list case, I guess. I sometimes use another exception to the 3rd rule, to highlight `nil' as a return value, especially if there are many side-effect else clauses or some of them are complex. E.g.: (defun foo () (if condition nil ; Return nil (do-aaaa) (do-bbbb) (do-cccc) ... (do-zzzz) result)) That can sometimes be clearer than, say: (defun foo () (and condition (progn (do-aaaa) (do-bbbb) (do-cccc) ... (do-zzzz) result))) (I tend to avoid `progn' too.)