When working on a larger lisp code base, one with 10+ files in one
package, I begin to get nervous about accidental name conflicts, and was
wondering how other people deal with this.

Here's the scenario I'm worried about:

    * dsl.lisp, written by a coworker two years ago, has a number of
      small functions that are helpers for the main #'WRITE-DSL-REPORT
      function; one of these helpers is #'GET-WAN-IPS
    * nagios-config.lisp, written by me today, has a number of small
      functions that are helpers for the main #'WRITE-NAGIOS-CONFIG
      function; one of these helpers is #'GET-WAN-IPS
    * I miss the compiler warning about redefining #'GET-WAN-IPS
    * I test my code, it works in my REPL so I commit and call it a day
    * Code eventually gets pushed to production and #'WRITE-DSL-REPORT
      is broken

It doesn't happen very often (and testing procedures usually catch stuff
before it goes to production), but it seems like there should be a nicer
way to deal with helper functions that you want to develop/test from the
REPL, but don't need to be used outside the current file. 

I had a few ideas to solve it, none of which I really like.  I could add
a top-level FLET for the file, but the extra indentation will be
annoying and it'll be harder to test/maintain those helper functions.  I
could define a helper package, per-file, and put my helper functions in
that package (e.g. (defun nagios-config-helpers::get-wan-ips ...)), but
that feels funny and awkward, which usually means it's a bad idea.  I
could break up my code into many smaller packages, each exporting and
importing the functions needed elsewhere in the system, but that seems
like recipe for dependency headaches and a lot of unneeded paperwork.

Do other people have this anxiety?  Are there elegant ways to deal with
it? (besides medication and more unit testing)

Thanks,

-- 
Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506

_______________________________________________
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro

Reply via email to