Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: Robert Dewar <dewar@adacore.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
		  Markus Deuling <deuling@de.ibm.com>,
	 Eli Zaretskii <eliz@gnu.org>,
		  pkoning@equallogic.com,  eager@eagercon.com,
		  stanshebs@earthlink.net,  gdb@sources.redhat.com
Subject: Re: What's an annex? stratum?
Date: Wed, 27 Jun 2007 00:32:00 -0000	[thread overview]
Message-ID: <m33b0e8cf8.fsf@codesourcery.com> (raw)
In-Reply-To: <4681A48E.8060201@adacore.com> (Robert Dewar's message of "Tue, 26 Jun 2007 19:43:10 -0400")


Robert Dewar <dewar@adacore.com> writes:
> It is hard to read into this a viewpoint that says that time spent on
> the internals documentation is OK if it is in the source files, but not
> if it is in separate files.

You're right; this doesn't make sense as written.

I write the comments in the code before I write the code, because I've
found that the effort of trying to explain what I'm about to try to do
helps clarify my own understanding a great deal.  For me, at least, it
makes enough of a difference that I'm sure I come out ahead, if you
include debugging time.

In other words, if the internals documentation is written before the
code, then, for me, it is a worthwhile investment.  In that case, I do
believe that writing that documentation brings the completion date
closer, and I write it.  I don't know whether other contributors need
this particular crutch; I'm pretty sure some don't.

The only other time I write explanations is when someone asks for
help; here, again, the investment is worthwhile, because someone is
about to go off and write some code, and I can bring their completion
date closer.  Most of what I've contributed to gdbint.texinfo got in
there because Eli liked something I'd written on the mailing list and
asked me to put it there.

Documenting other code after it's designed and written doesn't have
either of these benefits.

I hate arguing against having clear explanations that make the system
transparent to all comers.  Who wants to be the party pooper?  I
brought up the well-commented code I have written as proof that I do
value quality and clarity, not specifically as evidence for or against
internals documentation.  It happens to be evidence for, but only in
specific circumstances.


  reply	other threads:[~2007-06-27  0:32 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-23 18:01 Michael Eager
2007-06-23 18:57 ` Stan Shebs
2007-06-23 19:08   ` Michael Eager
2007-06-23 19:47     ` Eli Zaretskii
2007-06-23 20:51       ` Michael Eager
2007-06-23 21:23         ` Daniel Jacobowitz
2007-06-23 21:40           ` Michael Eager
2007-06-24  2:58             ` Eli Zaretskii
2007-06-24  4:32               ` Michael Eager
2007-06-25 18:03     ` Jim Blandy
2007-06-25 18:39       ` Michael Eager
2007-06-25 19:10         ` Jim Blandy
2007-06-25 19:26           ` Paul Koning
2007-06-25 19:32             ` Daniel Jacobowitz
2007-06-25 19:38               ` Robert Dewar
2007-06-25 19:48                 ` Paul Koning
2007-06-25 20:09                   ` Michael Eager
2007-06-25 20:40                     ` Robert Dewar
2007-06-25 20:47                       ` Robert Dewar
2007-06-25 20:31                 ` Eli Zaretskii
2007-06-25 20:44                   ` Robert Dewar
2007-06-25 21:00                     ` Eli Zaretskii
2007-06-25 21:03                       ` Robert Dewar
2007-06-25 21:06                         ` Robert Dewar
2007-06-26 18:34                   ` Markus Deuling
2007-06-26 18:36                     ` Robert Dewar
2007-06-26 21:55                     ` Jim Blandy
2007-06-26 22:14                       ` Nick Roberts
2007-06-26 23:26                       ` Robert Dewar
2007-06-26 23:39                         ` Joel Brobecker
2007-06-26 23:43                           ` Robert Dewar
2007-06-27  0:32                             ` Jim Blandy [this message]
2007-06-27  0:42                               ` Robert Dewar
2007-06-27  3:22                                 ` Eli Zaretskii
2007-06-27  0:23                       ` Michael Eager
2007-06-25 20:42             ` Eli Zaretskii
2007-06-25 20:23           ` Eli Zaretskii
2007-06-25 21:52             ` Jim Blandy
2007-06-26  1:04               ` Paul Koning
2007-06-25 20:37         ` Eli Zaretskii
2007-06-25 20:15       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m33b0e8cf8.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=deuling@de.ibm.com \
    --cc=dewar@adacore.com \
    --cc=eager@eagercon.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=pkoning@equallogic.com \
    --cc=stanshebs@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox