2010-10-28



Currently I'm trying to become familiar  with  nmh's  code  base.
First  I  started  to  read the parts in which I want to work in.
Unfortunaetly they are pretty complex and I was just  staring  at
the  code  more and more without getting smarter.  Thus I started
again with the simple parts of nmh and am increasing the level of
complexity  of  the code I read steadily.  This is much more suc-
cessful.  This way, I have several small feelings of success over
the day, which is very good.

Code reading is a task one should do more  often.   You  discover
lots of interesting stuff.

From sbr/error.c:65-75 of nmh:

     /*
      * main routine for printing error messages.
      *
      * Use writev() if available, for slightly better performance.
      * Why?  Well, there are a couple of reasons.  Primarily, it
      * gives a smoother output...  More importantly though, it's a
      * sexy syscall()...
      */
     void
     advertise (char *what, char *tail, char *fmt, va_list ap)
     {

No matter how enjoyable such a comment is to read, it  is  simply
bad  to  keep  such code.  It introduces #ifdefs, complexity, and
reduces protability.

The Linux man-pages project writes for writev(2):

     BUGS
     It is not advisable to  mix  calls  to  functions  like
     readv()  or writev(), which  operate  on  file descrip-
     tors, with the functions from the  stdio  library;  the
     results  will  be  undefined  and probably not what you
     want.

Is writev(2) still so sexy?

I believe in: ``Good code is dumb code''  ...  but  does  quality
then mean the end of creativity?


Something other:

It is often advertized to write robust code -- code that does not
fail  on  little errors.  But now I'm not so sure anymore if this
is really good.  I'd say, write first and foremost for readabili-
ty, because that's what we (should) do with Free Software.  Let's
take this bit of code:

     if (array->size >= array->max) {
             /* realloc */
     }

What really is meant is:

     if (array->size == array->max) {
             /* realloc */
     }

Now, what is to prefer?

As I needed some time to find out why a greater-than  check,  in-
stead  of  the more exact equality check, was made, I tend to the
latter one, no matter that this  is  often  assumed  to  be  less
robust.   If  a  situation of greater-than would ever occure, the
program should better fail heavily, as there must be  some  fault
somewhere else then.

Seems as one should try to write exact code.  Robustness, though,
is importent in other ways nontheless.



http://marmaro.de/lue/        markus schnalke <meillo@marmaro.de>