next up previous
Next: Program Design Language Up: Designing and Documenting Individual Previous: Writing Code for LPS

Writing Documentation for LPS

Documentation chunks are not so easy to describe. Since every routine is different, every explanation is different. McConnell suggests the use of a program design language or PDL. In the case of pure computer science work, this may be a good approach. In scientific programming, though, one would expect to see much more mathematics. While approaches differ, the result should be the same: a clear, concise written document that can be read by anyone reasonably competent in programming. LPS makes discussion of the problem much easier.

It is the author's experience that there is a shift in emphasis from the design-implementation phase and the implementation-debugging-testing phase. During design and implementation, LPS makes record keeping easy and thus encourages the use of literate programming; you can leave ``postit notes'' of things to do later or suggestions for improvement. Documentation during design and implementation is usually short passages, maybe even just fragments. These notes are ignored for the compilation but can be much more extensive than comments as allowed by the language itself. When it is time to write the final documentation we have all our notes in one spot. This is particularly hand for a group project when several people are working in the same module.

Because of the the flexibility of noweb, we can also store test data and test cases in with the code. This takes some advanced uses of tangle and not every systems is this flexible. We will suggest an approach that is sure to provide good documentation. This will be to use the PDL to link the pure narrative and the pure code.



Steve Stevenson
Wed Feb 26 10:54:45 EST 1997