emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Thorsten <quintfall@googlemail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Elisp programming style
Date: Fri, 28 Oct 2011 17:52:41 +0200	[thread overview]
Message-ID: <86k47pqfjq.fsf@googlemail.com> (raw)
In-Reply-To: 87fwiduqti.fsf@gmail.com

Eric Schulte <schulte.eric@gmail.com> writes:

Hi Eric, 

> Hmmm, this looks suspiciously like the case in some Babel functions :)

well ... ;)

> in which we originally has instances of the first style and then had to
> manually transition to the second.  IMO the first is very poor form, the
> variables are technically "free variables" when defined in the helper,
> and just through undocumented variable capture does the execution work
> out correctly, this can lead to unpleasant bugs.
> The means the helper may only be used when variables of certain names
> are in scope.
> If you do want to use a helper which uses variables in scope which
> aren't passed as arguments (again just my opinion) you should defined
> the helper function using `flet' *inside* of the main function and the
> scope of the variables.

That sounds like an operational prescription to me, and I think will
follow this advice in the future.

>> Would that be considered bad style from the original author, or is that
>> up to personal choice and not considered a problem?
> I don't believe we have an official canon of such rules, but personally
> I would consider this to be bad style.  If the helper function is only
> used in one main function then it should be defined using flet, if it is
> used across multiple functions then the in-scope variables should be
> passed as explicit arguments (preferably with names other than those
> which it has in scope so you can be sure you are actually using the
> arguments).
> Finally, I believe the emacs-lisp compiler would complain about such
> free variables.
> Hope this helps, Best -- Eric

yes that helped, thanks


  reply	other threads:[~2011-10-28 15:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-27 18:03 Elisp programming style Thorsten
2011-10-28 10:17 ` Štěpán Němec
2011-10-28 14:09   ` Thorsten
2011-10-28 14:31     ` Nick Dokos
2011-10-28 15:59       ` Thorsten
2011-10-29  2:13       ` Eric Abrahamsen
2011-10-28 14:34     ` Tassilo Horn
2011-10-28 14:40       ` Eric Schulte
2011-10-28 16:04       ` Thorsten
2011-10-28 14:35     ` Eric Schulte
2011-10-28 15:52       ` Thorsten [this message]
2011-10-28 17:43     ` Tom Prince
2011-10-28 18:05       ` Thorsten
2011-10-29  7:43         ` Tassilo Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86k47pqfjq.fsf@googlemail.com \
    --to=quintfall@googlemail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).