TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Simon Wright <[log in to unmask]>
Reply To:
Simon Wright <[log in to unmask]>
Date:
Sat, 6 Jul 2002 07:30:24 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
> From: Jean-Pierre Rosen <[log in to unmask]>
>
> > The normal one is the semicolon count. However, this seems to us to be
> > misleading especially when preparing for Fagan inspections, where
> > there's an external "standard" for the number of lines you can
> > properly do in one inspection (about 250, IIRC). For that purpose, we
> >
> >   eliminate comments
>
> That's strange. When I review code, I certainly count comments in
> the lines to be reviewed!  Quite often, reviewing comments takes
> longer than code...

The point of the line count in Fagan inspections is to ensure that you
don't try to inspect too much in one go.

So the limit of 250 LOC suggested by Michael Fagan is derived from
studies he conducted at IBM which showed that the effectiveness drops
after that. Remember the process says that you have 4 inspectors,
spend up to two hours preparing, then up to two hours in the
inspection; it's a fairly demanding experience, and after 2 hours
you're bushed.

There's likely to be a strong correlation between bytes in file/source
lines/non-blank lines/non-blank non-comment lines/semicolons, of
course, so in a sense you can choose the cutoff you like; but it's
easier to persuade management that you really need all that time for
inspections using an external consultant's figures (appeal to
authority) than ones you invented for yourself.

I'm pretty sure MF treats the comments as "background material" for
the code, so you would certainly read them in an inspection and we
would definitely raise defects against them. In the case of a body
these would not likely be operational (major) defects, but for a spec
I think they well might since they have the potential to cause other
programmers to mistake the correct usage of the package. I don't know
how much Ada (or other language with clear separation between spec and
body) MF has studied! but in any case it's up to the organisation to
make its own mind up on policy here, MF just gives you a starter.

ATOM RSS1 RSS2