Re: [Nmh-workers] Questionable code - the bigger picture

[Josh Bressers]

> I'm not convinced of the need to start a separate branch for this.  I haven't
> yet run across anything that requires this.  But, I can be convinced.

It was merely a suggestion.  I'm not completely for or against it.  It was
just a thought.

> What sort of things do you think need to be done to nmh?  My list is pretty
> small:
>       1.  Clean up the code.  Make it use more modern (at least Posix)
>           system features, get rid of code that was there to work with
>           really broken systems.  Document the code.
> 
>       2.  Add a few small features such as the aforementioned -nochangecontex
> t.
> 
>       3.  Improve the reading end of mime mail.  I've brought this issue up
>           before and have ideas on how to do this.
> 
> So what else needs doing?  Let's put together a plan to do it.

I think you've hit the nail on the head with your list.  #1 being the most
important task.  I've already submitted a few patches to the patch system
in savannah, with much more work to be done.

The steps I see for #1 are as such:
 - Better error checking/handling (I found a number of unchecked malloc
   calls for example)
 - Less duplication.  There is a ton of code duplication.  There are also a
   number of functions I've seen that POSIX can handle.
 - Better modularity.  All the executable are static, and the current
   layout of source lacks clarity.  There are subroutine files in uip, they
   belong in sbr (perhaps renaming these directories would be nice too).
   We should strive for nmh to really be 2 parts.  mhlib, and the user
   interface bits.
 - Naming clarity.  Right now it appears all the functions and variables
   are named whatever the author wanted to call them.  I think some naming
   and style guidelines are in order.

That's probably a good start for now.  There is of course more that needs
to be done, but I'm sure once a structured code cleanup starts, the tasks
will become more apparent.

Adding documentation is of course a given.  I've used doxygen in the past,
it makes for rather nice API docs.  I think keeping our documentation as
close to the code as possible will help keep it accurate and useful.

-- 
    JB