Documentation: Difference between revisions

Quite useful documentation could be extracted just from that. By mixing actual source statements with the commentary and extracting ''both'', tedious clashes can be reduced, as in <code>CHARACTER*6 T !Three-character name.</code> because a modification to the nature of the parameter had been made, but, the programmer's consciousness faded out as soon as it saw the comment start and noted "non-Fortran source". A system that extracted only the commentary part from that would not give a correct report, whereas with it known that the actual declaration would be included, there would be no longer any need to repeat its details in the comment and the comment could confine itself to expounding on meaning and usage.

Similarly, there could be a convention in the file-naming scheme whereby a code file could gain access to its source file, and with further conventions put to use, it could recognise its own commands and messages and nearby find further text with explanations or examples, etc. or indeed find its own manual and print it on request. It is ''much'' better to have one file (and to maintain synchrony within it), than to have two separate files, possibly maintained by personnel in two different departments who speak different languages. An accomplished programme might even modify its own source code, say to maintain a version number - if the source code's value matches the compiled-in value then this is the first run of the new version, so increment the counter in the source code. By keeping track of the date and time, and the timestamp of each user's last use, then a user could be advised of changes to the system since their last use. Given that the update log is also within the source file and suitablesuitably identified and timestamped.