Re: Subroutine header
- From: Mark Westwood <markc.westwood@xxxxxxxxx>
- Date: Mon, 12 May 2008 08:24:36 -0700 (PDT)
Hi Stefan
I used to write headers like those, these days I lean more on my
toolset to keep that kind of information for me. For example:
-- I use the Subversion version control system to maintain key
information (such as revision, last modification date, etc) in source
files.
-- I use a build script which writes a build log containing all the
compilation and linking details. These logs go into the version
control system, and I use the MD5 hash of the built executable in the
log to ensure that I can later tie the two together without doubt. We
use several compilers here, spend a lot of time tuning the options, so
need an automated way to record this info -- which 'belongs' to the
binaries anyway, not the source code. Make make your friend (or learn
SCons or use your favourite scripting language).
-- I no longer keep modification details in source files. I write
notes in comments as I develop but when the code is submitted for
build for production release I (in line with site standards) strip out
all such commentary. In my experience (guess who wrote the site
standards) most of the modification notes I ever saw were useless,
even the ones I wrote myself a short while later. One of my
colleagues used to never delete a line of code or commentary from any
source file when he modified or enhanced it. After the ratio of
commented out lines plus comment lines to code lines goes over 5:1
(say) you begin to understand why some people say all comments are
bad.
-- Argument details go in comments next to their declarations at the
head of sub-programs.
-- We have an old utility knocking about (called ???) to create call
graphs. If I was concerned I'd use it rather than rely on what
someone may or may not have written correctly and clearly into a file
header. Lots of interdependencies between modules and programs make
this unsuitable for source file headers anyway.
So, my general rules are these:
a) If file header information can be maintained automatically then use
the right tool to maintain it.
b) If it can't be maintained automatically then it won't be maintained
manually, so don't bother.
c) If you don't have the right tool buy it or build it -- it will
always be worth the expense or effort.
In spite of (b) I do put into file headers comments about the intent
of the source, perhaps a specification of the algorithm it implements
or the problem it solves.
Regards
Mark Westwood
On May 11, 10:58 pm, Stefan <stefan@xxxxxxxxxxxxxxxxx> wrote:
When writing programs/subroutines I usually give them 'header' like
this:
PROGRAM/SUBROUTINE EXAMPLE(a,b,...)
! Version: 1.01 Last modified: 11.01.2001.
! Parameters: a - first parameter
b - second -||-
! Calling: list of subroutines it calles, if any ...
! Part of: if part of a greater program (exclusivly)
! Compiled and tested with: CVF66c
! Modifications:
! - version number / date:
! short description of modification
Do you have a similar habit and what do you include in those headers?
How do you organize larger programs and determine what a certain
subroutine does after not looking at it for a while ?
Stefan
.
- References:
- Subroutine header
- From: Stefan
- Subroutine header
- Prev by Date: Re: Identifier name length in g77
- Next by Date: Re: derived type as argument
- Previous by thread: Re: Subroutine header
- Next by thread: Identifier name length in g77
- Index(es):
Relevant Pages
|
Loading