HDTenEightyP/NetNews huggingface dataset:
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: Value of High Code Coverage Metrics in Testing - Request for Opinion
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 18 Dec 1992 17:48:38 GMT

I have little to add to the previous answers to this question.  I'd
like to reinforce a couple of points:  

- 100% coverage is possible for many programs.  The problem is far
more often test implementation than test design.  A lot of times, a
little test support code in the program can make those implementation
problems tractable.

- Coverage is bad at finding the most important class of bugs, faults
of omission.  These are bugs that are fixed by adding code, like the 
following IF:

	if (c != 0)
		a = b / c;

Designing tests around coverage is not helpful in finding faults
of omission and may be harmful (because it focuses your attention in
the wrong place).  Don't do it.  Design your tests elsewise, then use
coverage as an indirect measure of their quality.

- Partial coverage goals (be they 60% or 85% or whatever) are
dangerous.  Given an easy, measurable goal (reach X% coverage) that's
only indirectly related to the true goal (find all the bugs), it's
incredibly easy to blindly achieve the easy goal at the expense of the
true one.  You start with a list of uncovered branches and just go
down the list, writing the easiest possible tests that force them,
until you've hit the required percentage.  Those easy tests are
probably bad.

- Other types of coverage besides branch are useful.  In situations
where I would use branch coverage, I use three other types:  loop,
relational, and multicondition.  See the GCT documentation (info
below) for more.


I've previously posted a description of how I used a coverage tool to
test itself.  I won't post it again, but I'll mail it to anyone who
missed it the first time.

Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README










Newsgroups: comp.software-eng
From: dave@digicomp.com (Dave Bulatek)
Subject: Re: Project Planning Software
Organization: DIGICOMP RESEARCH CORPORATION
Date: Tue, 15 Dec 92 15:40:15 GMT

Tom Downey requests...

> We are in need of a good project planning package.  We have evaluated several
> products but are not satisfied with any of them.  
>
> Can anyone suggest any good products?  It should run on Unix/X-Windows.

I am currently evaluating AutoPLAN. It was written for OpenLook but they
do have a version now that runs under X. I've only spent a day looking at
it so far. I appears to have most of the features that we need. I also
like the look and fell for the most part.
Found a minor bug in the Gantt chart that deals with a missing
label (the vendor says that it will be fixed in the next release due out 
in January). AutoPLAN was created by Digital Tools, Inc, 18900 Stevens Creek
Blvd., Cupertino CA  95014.  The number I have for them is 1-408-366-6920.
We acquired the evaluation copy from UniPress, 1-908-287-2100.

I tried using MasterPlan by QSP. Was not happy with their look and feel and 
entry methods. I also had a problem running MasterPLan and eXclaim (a QSP
spreadsheet package) simultaneously. They apparently use the same 
user-server and that created conflicts with the setup. In addition, QSP has
not been very responsive with the problems that I had encountered in eXclaim
(that is, they confirmed the problems but couldn't tell me when they would
fix them. We bought it last March, they only fixed a few since then).
(enough flaming)

Tom, what packages have you evaluated and what didn't you like about them?
Do you have a need for features that these products don't satisfy? (e.g. I
would like to be able to show many milestones on one line on a Gantt chart.
I would also like to show re-occuring tasks on one line.)


-- 
Dave Bulatek
Digicomp Research Corp.
Internet e-mail: dave@digicomp.com
From: titus@dallas.sil.org
Newsgroups: comp.software-eng
Subject: Re: C code layout
Date: 17 Dec 92 11:58:35 CST
Organization: Summer Institute of Linguistics, Dallas Center

daves@hpopd.pwd.hp.com (Dave Straker) writes

>On balance, I'd probably do a bit of both. I'd also get students
>to mark one another's work for both, thus saving a bit of lecturer's
>effort whilst simultaneously letting them find out the value of
>using a style with which other people are familiar.

    I think Dave is on to something with requiring students 
to go over each other's work.
    I have personally done A LOT more maintenance work than 
new development, so I think I can safely speak for the poor 
maintenance hack who has to come in (sometimes MUCH!!) later 
and try to figure out what is going on.  I have also 
occasionally had to go back to my own code long after 
forgetting why I did something that looks dumb at first 
glance.  As a result, some of my code may contain several 
lines of comments to explain a short code fragment.

For example:

  /* RT-11 normally caches the directory of the last device read.     */
   /*  If another tape, disk, or whatever is inserted in that drive,  */
   /*  it still assumes it has the correct directory.  To get around  */
   /*  this, we do a dummy open on SY:, since we assume that most     */
   /*  input files will be on DK:.  That way, when we attempt to open */
   /*  a file on DK:, it doesn't have the directory in memory and     */
   /*  will actually read the directory.  Otherwise, we may get a     */
   /*  "File not found" when the file is actually there.              */

      fopen("SY:Z.X", "r");

    My own experience (first 2-3 years professionally 
writing device drivers in assembler) taught me the absolute 
NECESSITY of putting good comments in the code, especially 
re: register usage.  I later did a maintenance job on a 
15,000+ line C program which had previously been worked on 
by an ex FORTRAN jockey.  Talk about terse, non-intuitive 
variable names!
    I now tend to, even when sketching out an algorithm on 
paper for someone, add comments as a matter of course.


               * * * * * * * * * * * * * * * * *
Mike Titus, Programmer                  /\   Summer Institute
SIL                                    /  \        of
7500 West Camp Wisdom Road            /SIL \   Linguistics
Dallas, Texas  75236-5699            --------
U.S.A.
Voice    : (214) 709-2400		* Internet <titus@dallas.sil.org>
Facsimile: (214) 709-3387		* UUCP     ...utafil!txsil!dalsil!titus

"I can do everything through Him who gives me strength."

						Philippians 4:13 (NIV)

Newsgroups: comp.software-eng
From: lfd@cbnewsm.cb.att.com (Lee Derbenwick)
Subject: Re: C code Layout
Organization: AT&T
Date: Tue, 15 Dec 1992 18:04:36 GMT

In article <KANZE.92Dec15171105@slsvdnt.us-es.sel.de>,
kanze@us-es.sel.de (James Kanze) writes:
  [ in answer to one of my comments on excessively large comments: ]
> |> One reason that I personally dislike very large comments embedded in
> |> the code is that they greatly reduce the amount of code within my
> |> visual field (whether on a screen or on paper)  [ ... ]
> 
> I was surprised that this argument wasn't mentioned earlier in this
> thread, as it seems quite popular, at least amongst Cambridge
> graduates, where it seems to be called the band width theory.  [ ... ]
> 
> Of course, this means that you also put several short statements on
> the same line, code on the same line as the opening brace, etc.  And
> of course, you never, never leave a line blank.
> 
> This also argues for short variable names.  (They increase the chances
> of getting more than one statement on a line.)

Let's start with the opposite extreme.  Should we mandate 1000 lines
of comments for every line of code?  No?  Okay, "We've established
what you are, now I'm trying to establish your price."  :-)

Certainly at _some_ point you have too many comments.  Similarly, if
you make the code too dense, it becomes unreadable.  The question is,
where is the appropriate point?  The "band width theory" is a useful
metric, but it is only one of the driving forces.  "Chunking" of
concepts has already been mentioned in this thread as another driving
force.

Just taking these two into account can lead to some guidelines for
where large comments should be.  A 10-line comment detailing a tricky
(but not terribly long) loop is likely to interfere seriously with
"chunking" if it is embedded in the middle of the loop.  But the same
comment, placed before the loop (and set off by blank lines!) will
convey the information without interfering with the visual cues.

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd
Newsgroups: comp.software-eng
From: chrisf@brtph316.bnr.ca (Chris Fulmer)
Subject: Want Configuration Management software
Keywords: CM CASE Configuration RCS 
Reply-To: woodstock!chris@mcnc.org
Organization: BNR Dept 3B91, RTP
Date: Fri, 18 Dec 1992 19:33:12 GMT

Hi there. 

  Our group has determined that the configuration
management system (An IBM mainframe based proprietary 
thing) which we are currently using is extremely inadequate
for doing any sort of serious unix software.  So, I am doing
the groundwork on coming up with a new one for our group.
I was hoping for feedback on any systems which people are
using/contact information/etc....  I have read the FAQ
questions & answers, but need to go into more detail.

As alluded to earlier, I'm interested only in UNIX based
CM systems, mainly things that will run on HP equipment.

If you're a vendor of such a system and want to respond,
but don't want to do so via E-mail, you can send USmail to...

Chris Fulmer
BNR INC, Dept 3c76
35 Davis Drive
Research Triangle Park, NC 27709-3478

If I get a lot of responses, I will post a summary message.

Thanks.

------------------------------------------------------
Chris Fulmer                    Bell-Northern Research
Sr. Software Designer            Research Triangle, NC
mail to woodstock!chris@mcnc.org (preferable) or...
        chrisf@bnr.ca            (not so preferable)
Oh yeah.  The usual disclaimers apply here.
From: zaphod@cs.mcgill.ca (Morris BERNSTEIN)
Newsgroups: comp.software-eng
Subject: Re: Books on debugging
Date: 15 Dec 92 18:21:10 GMT
Organization: SOCS - Mcgill University, Montreal, Canada

In article <1992Dec9.214306.3427@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>
>Are there any books that teach debugging?

If there are any, I'ld like to know about them too.

I was in the library today, chasing down an unrelated reference, and
(serendipity) I found a series of articles in some recent conference
proceedings.

"Session 7: Developing Software Engineering Expertise"
Software Engineering Education: SEI Conference 1991 (Pittsburgh, Oct. 1991).
Published as "Lecture Notes in Computer Science 536" (Springer-Verlag).

I haven't had time to read the articles yet, but they were about
AT&T's development of a course in debugging.

Hope this Helps.


Morris
-- 
Morris Bernstein	zaphod@binkley.cs.mcgill.ca
School of Computer Science, McGill University, Canada

True skill is demonstrated when the job is made to look easy.
From: doug_d@sdd.hp.com (Doug Deprenger)
Newsgroups: comp.software-eng
Subject: Re: average identifier length (was Comments: Code...)
Date: 18 Dec 1992 00:37:00 GMT
Organization: Hewlett-Packard, San Diego Division
Distribution: world
NNTP-Posting-Host: hpsdl126.sdd.hp.com

In article <1992Dec16.080001@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
|> mueller@b30news.b30.ingr.com ( Phil Mueller ) writes:
|> [argument that you should use ii instead of i, so that you can find it with
|> a text editor, followed by suggestion that vi can find isolated i as a
|> token]
|> >So you're going to force everyone to use vi?
|> >AAAARRRRGGGGHHHH!!!!
|> 
|> No, nothing of the sort, and dammitall, we've already been over this:  The
|> idea is to use a decent tool.  vi was an example.  If you want to consider
|> vi a horrible, archaic editor, I won't argue.  (I've used it for a decade,
|> but I'm a horrible, archaic man.:-)
|> 
|> Take it this way: If even stupid old vi can easily distinguish isolated "i"
|> from the letter embedded in other words, surely any decent editor can do so
|> at least as easily.
|> 
|> THE TOOL IS THE SERVANT, NOT THE MASTER!!!
|> 
|> (pardon that sticky caps-lock key...)
|> 
|> If the tools you've got are an impediment to writing and manipulating code
|> the way the rest of the world writes it, you've got crappy tools.  Throw
|> them away and get better ones.  Do not construct in your code misshapen
|> monuments to bad tools.
|> 
|> >I'm glad someone else uses the 'ii' technique.  Means that there's some
|> >code I may have to maintain someday that doesn't use 'i' <gag>.
|> 
|> The use of a single 'i' as an index variable spreads across more languages
|> than you've seen, and is backed up by centuries of mathematical usage.  It
|> *is* well-understood convention, and 'ii' is not.  This is not to say that
|> long-standing convention and historical precedent can't be wrong...but you
|> will need more than "AAAARRRRGGGGHHHH!!!!" and "<gag>" to justify flouting
|> so much tradition.
|> -- 

   One of the problems using 'i' is it looks like a numeric '1' or a small
   el 'l'.

   doug
From: crowley@zax.eda.teradyne.com (Chris Crowley)
Newsgroups: comp.software-eng
Subject: Configuration Management with vms and unix
Keywords: Configuration Management
Date: 16 Dec 92 16:31:44 GMT
Followup-To: comp.software-eng
Organization: Teradyne, Inc. Boston MA

-- Please note my e-mail address is crowley@maven.dnet.teradyne.com --
   (this usually gets mangled above).

I would like to hear from someone working in a mixed vms/unix environment; 
I am researching available options in configuration management/version 
control across those O/S's.  

I have used or examined some of the available products on either/both O/S 
(RCS, DEC's CMS, Atria's ClearCase, TeamOne's TeamNet, Aide-de-Camp).  

We are currently using a hodge-podge of tools, with extensive, 
under-designed, baroque sets of executables/scripts/command files layered 
on top of them.  Different projects have different O/S requirements; some 
are vms only, some are mixed; some are unix only.  One of the largest 
sources of pain for our developers is in those projects which span O/S.  
Currently the archive for those developers is on the vax, and the developer 
who needs to develop on a sun ends up going through a painful process to 
properly lock and push his files to his work area.  Of course, since it's 
painful almost everyone short-circuits this somehow.

Interaction with the archive is currently a large source of complaints from 
all groups;  I'd like to hear from someone who has solved this problem, 
particularly in regard to the vms/unix barrier.

If there is interest, I will summarize any e-mail responses I receive.


Chris Crowley   			crowley@maven.dnet.teradyne.com 
Newsgroups: comp.software-eng
From: tom_van_vleck@taligent.com (Tom Van Vleck)
Subject: Re: Software Inspections.  How many does it take?
Followup-To: comp.software-eng
Organization: Taligent Inc.
Date: Sat, 19 Dec 1992 04:55:17 GMT

mark neumann <neumann.m@apple.com> wrote:
> 
> Is a meeting necessary to accomplish a review?> 

The Multics group used one-person "code audits" on every change, even 
one-liners. The auditor would read a difference list and a new listing,
and could consult with the author if the code was hard to understand.
The audit package included design documents and draft user documentation
as well as the listings. We had very thorough design review and a well
established process.

At Tandem, we introduced Fagan-style inspections (order IBM manual 
GC20-2000-0) and found that they had a lot of overhead for small changes. 
We defined a "code review" process which could be used in place of
inspection
for simple, low-risk changes. We used the same checklists as the code
inspections, and reported defects the same way, but had only one reviewer
and didn't hold a meeting. 

There are additional intangible benefits to inspection/review:
- Sends message that the company cares about correctness
- Sends message that code should be right before debugging
- Promotes group cross training
- Encourages group ownership of quality criteria

The last point is crucial to effective inspection/review. Each group
must tailor its definition of quality and its checklists & criteria by a
consensus process; otherwise there's no buy-in. People have to take up
the spirit of quality and go beyond the letter; one way management
signals that it's OK to do this is to mandate inspection.

tom <tom_van_vleck@taligent.com>          (private opinions)
Newsgroups: comp.software-eng
From: rogers@ferranti.com (keith rogers)
Subject: Re: C code Layout
Keywords: comments
Organization: Ferranti International Controls Corporation
Date: Mon, 14 Dec 1992 23:37:56 GMT

In <1992Dec13.152430.6370@mixcom.com> ttvvtt@mixcom.com (Donald Amby) writes:
>
> <...> (R.T. Herbst) writes:
>
> >While directing the eforts of 125 people in producing the
> >A Data switching system for the Bell System- Good ol'
> >Ma bell-- I asked for a sample of code. I founr the comments to
> >be utter nonsense,. If one removed the code, the comments made no sense.
>
>   Excellent point!   The comments SHOULD make sense without the code.
>   I personally write code by doing the comments first.  If I cannot
>   describe in clear concise sentences what I am attempting to do,
>   then I obviously do not understand the problem.
>
>   I then add the code as I get the details of the implementation
>   worked out.

What you are describing (to me, anyway) is design notes.  I don't agree
that comments must stand by themselves.  A design, prior to coding,
should meet that criteria, but once the code is written, the comments
and code, together, should be used to convey the information necessary
for proper maintenance of the software.  Insisting that the comments,
without the code, be comprehensible, insures that your comments will
contain needless, redundant information.  Commentary should be used to
help people through obscure coding, and to document non-standard or
unusual coding, e.g., where the "obvious" coding method would be
different, and was not chosen for a specific reason.  (This, so some
future maintainer doesn't toss out all of your good work, after having
scratched their head over it for many hours and finally deciding,
incorrectly, that it would be quicker, better, and easier to simply
rewrite the code in a manner already rejected, than to try and fathom
what the original coder had in mind.)
>
> >It was better to let the code speak for itself. If fact the code
> >was hidden in by the comments. Certainly we need well commented code.
>
>   Organizations that are serious about quality should address the
>   comments as part of any code review.  Of course, if there are
>   no code reviews you will never see the comments until you have
>   to make changes to the code.

And you shouldn't be surprised to never see any comments, at all,
ever, if you never have code reviews.
--
Keith Rogers (rogers@ferranti.com)
(jus' me talkin', an' nobody else)
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: C Code Layout
Date: 15 Dec 92 01:12:08 GMT
Organization: UNC Department of Computer Science
In-reply-to: herbst@seq.uncwil.edu's message of 14 Dec 92 19:31:11 GMT

In article <1992Dec14.193111.20367@seq.uncwil.edu> herbst@seq.uncwil.edu (R.T. Herbst) writes:

	   I learned my lesson. Comments are essential.
	   Comments that obscure the code can make
	   reading the code very difficult. 
	   The code is where the actions is.
	   C language permits alongside commenting
	   So comment along side the code.
	   This allows the code to be continuous.
	   Well commented code is needed, but
	   Commenting is a small part of the entire process.
	   I doubt that there will ever be a agreement on this
	   subject. So what.

Well, there is the old idea of dialectic as an effort to find Truth, I
suppose. 
--
		Charles R. Martin/(Charlie)/martinc@cs.unc.edu
     Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
	    3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
     "Oh God, please help me be civil in tongue, pure in thought, and able
      to resist the temptation to laugh uncontrollably.  Amen." -- Rob T
Newsgroups: comp.software-eng
From: travis@eecs.nwu.edu (Travis Marlatte)
Subject: Re: Software Inspections.  How many does it take?
Organization: Rauland-Borg Corporation, Skokie IL
Date: Thu, 17 Dec 1992 23:20:54 GMT

In article <BzB9J2.2q2E@austin.ibm.com> dugal@austin.ibm.com (Doug Gray) writes:
>
>In article <1992Dec14.192008.15480@gallant.apple.com>, neumann.m@applelink.apple.com (mark neumann) writes:
> I would think that the author's ego would be a
>factor whether reviewed by 1 or by 20.  Their work is still being put on the line.  I
>can see how having the author be a part of the review can be a problem, though. 
>Generally, it seems that having the author as distanced as possible from the review
>is the best idea.

I disagree. The author must be a part of the review. The author(s) are
the only ones with historical knowlege necessary to explain the code
or design being reviewed. Their work is not being put on the line. If
I don't have the confidense to show my work to co-workers in the interest
of finding problems, why should I be allowed to ship it to my customers.
>
>review team signs off that the deliverable is acceptable, ALL members of the team
>become responsible for the quality of that product - in some ways more responsible
>than the original author.
>

When the bug is reported, the person watching over the code is responsible.
It doesn't matter who reviewed it. A sign-off is not to associate
responsibility but rather to document the process.

-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
Newsgroups: comp.software-eng
From: dws@menlo.cadre.com (David W. Smith)
Newsgroups: comp.software-eng
Subject: Re: Software Inspections.  How many does it
Date: 17 Dec 92 23:31:05 GMT
Article-I.D.: menlo.1992Dec17.233105.13228
Organization: Cadre Technologies Inc., Menlo Park Operation

In article <1992Dec17.180947.3574@den.mmc.com> mentions one of the downsides
of adding people to a review team.

>But mn wasn't talking about *independent* review teams.  He was talking about
>adding more people to a team.  In this case, I suggest that the amount/number
>of errors detected per person added to the team decreases rapidly for team sizes
>beyond four or five.

One cause that I see for the decrease in error detection in larger teams is
that people fall prey to the notion that their participation isn't really all
that important, and that the rest of the team will cover for them if they
aren't prepared.  To give the illusion of being prepared, they pick then nits
with inconsequential matters, such as grammar and spelling in comments, and
the review slows way down.

It helps here to assign specific roles.  For example, if I'm tasked with
reviewing code for memory leaks, I'm more likely to believe that the use of
my time is valuable (and less likely to hope that the team will cover for me)
and will make a greater effort to block out time to carefully review the code.

-- 
Dave Smith, Cadre Technologies Inc. - Database Tools Division
4500 Bohannon Drive, Suite 150, Menlo Park, CA  94025
Newsgroups: comp.software-eng