> 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.