Begging pardon, but this is starting to border on pomposity.

# 1    Thou shalt run lint frequently and study its pronounce-
#      ments with care, for verily its perception  and  judge-
#      ment oft exceed thine.
#
#
# Of course with GCC/EGCS/whatever there is no real "lint" program, which
# is the root of the disagreements between the compiler and NetBSD's lint
# (what NetBSD has as "lint" is in many ways a poor hack, not a real
# "lint"; though in other ways it can be better since it has a different
# outlook on things...).  "gcc -Wall -WBLAH" for any number of BLAHs is
# not really a replacement for lint, even when you have full prototypes.

BSD used to have a fairly decent "lint" program; if it's not the same
now as it used to be, what happened?

# Also, for portable code I still find the lint-style hint comments to be
# infinitely more useful than any GCC-specific syntax (and even where ISO
# C approves, such stuff is still not portable and I won't use it).  GCC
# would do well to heed the lint-style hint comments if it's going to make
# lint-like complaints.

I agree with this; however...

# > i really don't think it helps the readability of the code.  then
# > again, if i wish to, i can make things much unreadable anyway by using
# > !! and -~ or ~-.
#
# It obviously depends on what you mean by "readability", and note more
# specifically that I also included "future maintainability" in there too!
#
# You seem to be implying that fewer words and syntactic glue is better.

I would actually agree with this:  Use what you need, and no more.

# I'm saying that explict delcaration of the programmer's intent is much
# better, even if it means using more words and syntactic glue.

If the words and glue don't *need* to be there, they shouldn't be there.
If you can't read C code, you probably shouldn't be modifying it.

# You could declare your intent in a comment, but obviously there's no
# "win" there.
#
# Again, the relevant quotes from Henry's advice column:
#
# 3    Thou shalt cast all function arguments to the  expected
#      type  if  they  are not of that type already, even when
#      thou art convinced that this is unnecessary, lest  they
#      take  cruel  vengeance upon thee when thou least expect
#      it.

"Unwarranted chumminess with the compiler will invariably produce
undefined results when least expected."

#
# 6    If a function be advertised to return an error code  in
#      the  event  of  difficulties, thou shalt check for that
#      code, yea, even though the checks triple  the  size  of
#      thy  code  and produce aches in thy typing fingers, for
#      if thou thinkest ``it cannot happen to me'',  the  gods
#      shall surely punish thee for thy arrogance.

"Never check for an error condition you are not prepared to handle."

				--*greywolf;
--
NetBSD: My Computer Works!