From: Nick Dokos <nicholas.dokos@hp.com>
To: Thorsten <quintfall@googlemail.com>
Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: Elisp programming style
Date: Fri, 28 Oct 2011 10:31:26 -0400 [thread overview]
Message-ID: <18647.1319812286@alphaville.dokosmarshall.org> (raw)
In-Reply-To: Message from Thorsten <quintfall@googlemail.com> of "Fri\, 28 Oct 2011 16\:09\:07 +0200." <86obx1qkcc.fsf@googlemail.com>
Thorsten <quintfall@googlemail.com> wrote:
> Štěpán Němec <stepnem@gmail.com> writes:
>
> > On Thu, 27 Oct 2011 20:03:22 +0200
> > Thorsten wrote:
> >
> >> Hi List, doing some Elisp programming (in an orgmode context)
> >> recently, the following question with regards to the 'accepted
> >> programming style' for Elisp concerned me:
> >>
> >> How independent and self-sustained should helper functions be?
> >>
> >> I found some redundancy in elisp code, e.g. several (main and helper)
> >> functions that do exactly the same thing to extract the same specific
> >> args out of an argument list. My first reaction was, to factor out
> >> this extraction into the main function, and then call the helper
> >> functions from inside a (let ...) environment where the extracted
> >> args are stored in a local variable.
> >>
> >> But then I recognised, that the helper functions cannot be called
> >> independently anymore, but only make sense when called from this one
> >> main function with its local bindings.
> >>
> >> Is there a kind of convention in a case like this? Like: "Make every
> >> function, even a helper function, independent, and don't care about
> >> redundancy"? Just being curious
> >
> > Too bad you didn't give any concrete examples.
>
> The problem can be described easily:
>
> problem-specific helper-funcions (some redundancy avoided)
> ,-----------------------------------------------------------
> | (defun main-function (args)
> | (let ((var (assoc :key1 args))) ; extracting var once
> | ...
> | (helper-function1 ...) ; inside let using var
> | (helper-function2 ...) ; inside let using var
> | ))
> |
> | (defun helper-function1 ()
> | ...
> | )
> |
> | (defun helper-function2 ()
> | ...
> | )
> `-----------------------------------------------------------
>
You probably need let* though.
> vs
>
> standalone helper-functions (but redundancy)
> ,-------------------------------------------------------------
> | (defun main-function (args)
> | (let ((value (assoc :key1 args)) ; extracting var 1st time
> | ...
> | )
> | (helper-function1 ...) ; outside let
> | (helper-function2 ...) ; outside let
> | )
> |
> | (defun helper-function1 (args)
> | (let ((var (assoc :key1 args))) ; extracting var 2nd time
> | ...
> | ))
> |
> | (defun helper-function2 (args)
> | (let ((var (assoc :key1 args))) ; extracting var 3rd time
> | ...
> | ))
> `-------------------------------------------------------------
>
>
> > In general, if the helper function is only used in a single place and
> > isn't likely to be more generally useful, there might be no reason for
> > it to be a standalone function at all (other than modular programming,
> > which is always a good idea IMO).
> >
> > OTOH, if the helper function _is_ standalone and used in multiple
> > places, then there is no "redundancy", so I'm really not sure what you
> > mean.
>
> Is there a policy? Lets say, an org-library author thinks his helper
> functions will be of no use for nobody else and designs them
> non-standalone. A few years later somebody wants to write a similar
> library and trys to reuse some of the old helper functions, to no avail.
>
No policy that I know of. It's very much a matter of taste, how complicated
the functions are, whether they perform something generic or something really
specific etc.
> Would that be considered bad style from the original author, or is that
> up to personal choice and not considered a problem?
>
Not a problem - you can't predict the future. You do the best you can
with your current knowledge. You can always refactor in the future:
that's one reason that having the source code around is important. When
you refactor, you may be cursing the original author for the "bad"
decicions, but c'est la vie: at least, you have chosen a system where
*you* can do that and not depend on a third party: they might not even
be alive, let alone willing to do what you want.
Nick
next prev parent reply other threads:[~2011-10-28 14:31 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=18647.1319812286@alphaville.dokosmarshall.org \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=quintfall@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).