[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Elisp programming style
From: |
Nick Dokos |
Subject: |
Re: [O] Elisp programming style |
Date: |
Fri, 28 Oct 2011 10:31:26 -0400 |
Thorsten <address@hidden> wrote:
> Štěpán Němec <address@hidden> 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