Communition over implementations (was: [Zope-dev] Re: zope.sendmail
Retry fixes and new state machine.)
Dieter Maurer
dieter at handshake.de
Thu Mar 13 16:08:41 EDT 2008
David Pratt wrote at 2008-3-11 09:42 -0300:
>I think your response gets to the heart of the issue. For
>software to be useful, it is often more important for folks other than
>the author to understand it. This can only occur with communication.
>Sometimes it is the understanding of edgecases in particular, that gets
>lost over time.
The are different understanding levels: e.g. the level of understanding
needed by the user of a piece of software and the level of understanding
needed by its maintainer.
I use e.g. "gcc". To do this, I need a basic understanding of the
programming language, the compilation process, the "gcc" options and arguments
and how they influence the compilation and build process.
I need nothing to know about edge cases in the compiler implementation.
I also do not need doctests -- not even those that provide
examples for the various options (think e.g. of doctests for the
options "-m64", "-Wunused-label", "-O3" -- all of them are better
described by words (only) rather than doctests).
Would I be a "gcc" maintainer, I would need a very different understanding.
Tests would be vital (though not necessarily doctests).
However, more important would be a good understanding of compilation
concepts and how they have been implemented in the "gcc" implementation.
I find another point essential: communication is not limited
to tests. I find tests (examples) a bad communication vehicle
-- see the "gcc" examples above. A clear concept description
and an outline how the concepts are used in the implementation,
well chosen names, good source code comments at difficult places
are additional communication means -- often better ones as
doctests....
> ...
>If the test is worth writing, it is not difficult to add a small amount
>of text to communicate about it. If the software is worth writing in the
>first place, I consider the code incomplete without doctests. For
>community projects, it is often the case that it is not the author
>maintaining the code in the future. This only strengthens the argument
>for doctests and the reason this has become the standard for zope.
There are other means beside "DocTest"s for communication and documentation --
often better ones....
--
Dieter
More information about the Zope-Dev
mailing list