HDTenEightyP/NetNews huggingface dataset:
From: amby <amby@mixcom.mixcom.com>
Subject: Re: C code Layout
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Distribution: usa
Date: Sun, 13 Dec 1992 15:24:30 GMT
Keywords: C code layout

In <1992Dec12.122453.8582@seq.uncwil.edu> herbst@seq.uncwil.edu (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.

>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.
-- 
Donald E. Amby
    don@amby.mixcom.com   (for short mail)        (414)797-6713 (voice)
    amby@eisner.decus.org (for lengthy mail)      (414)797-6533 (FAX)
    Harnischfeger Engineers, Inc., P.O.Box 1512, Milwaukee, WI 53201-1512
From: downey@tripos.com (Tom Downey)
Subject: Project Planning Software
Summary: need suggestions on project planning software
Keywords: project planning
Organization: Tripos Associates, Inc.
Date: Mon, 14 Dec 1992 16:01:28 GMT


Hi,

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.

Thanks, and sorry if this is a FAQ.

Tom Downey	downey@tripos.com
Newsgroups: comp.software-eng,comp.specification
From: pattis@cs.washington.edu (Richard Pattis)
Subject: IBM, FAA, Air Traffic Control Software
Summary: $3.8 billion contract
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Sat, 12 Dec 92 00:46:55 GMT

Today's NYT Business Section had a small article about IBM falling 18 months
behind on this project. Anyone know interesting details. This seems like a
big problem in a very large piece of software that Mr/Ms J Q Public deals with
daily in a safety-critical application area. I haven't heard other problems of
this magnitude discussed in public.

Rich Pattis

-- 
------------------------------------------------------------------------------
  Richard E. Pattis                     "Programming languages are like
  Department of Computer Science         pizzas - they come in only "too"
    and Engineering                      sizes: too big and too small."
From: wood@siemens.com. (Jim Wood)
Newsgroups: comp.software-eng
Subject: Re: C Code Layout
Date: 11 Dec 92 13:16:08 GMT

My format for C code modules:

/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Module:  X.C
   Purpose: ....
   Author:  Jim Wood, Siemens Corporate Research, Inc. (609) 734-3643
   Group:   Software Testing
   Project: SSP (Sample Stupid Project)
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Functions defined in this module:
	Add:			Integer X Integer --> Integer
	Is_Positive:		Integer --> Boolean
   Macros defined in this module:
	MINIMUM:		Integer X Integer --> Integer
	MAXIMUM:		Integer X Integer --> Integer
   Data types defined in this module:
	complex_number:		{Integer, Integer}
   Global variables declared in this module:
	Generate_Identifier:	unique identifier increment
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

#include "type.h"		/* data type definitions */
#include "universe.h"		/* macros and constants for all modules */
#include "a.h"			/* modules related to this one */
#include "b.h"
#include "c.h"


INTEGER Add(a, b)
  INTEGER	a,		/* first integer to add */
		b;		/* second integer to add */
/*
  PRE  A precondition goes here.
  POST The sum of two integers is returned.
  GENL General comments go here.
  NOTE Special notes, especially for maintenance, go here.
*/
{
  INTEGER	index = 0;	/* local integer variable */

  return(a + b);
} /* end ADD */

....

The point is to define standard header comments for the module, write
comments for each routine in the module, write short descriptive comments
for each formal parameter and local variable of each routine, and also to
identify the end of a routine.

Clarity and brevity are the main keywords.  If people are to understand
the code, the need to quickly know what each routine does and what each
variable means.

--
Jim Wood [jwood@siemens.siemens.com] (609) 734-3643
"Rise up on the wings of eagles, and two step among the stars.
 You are not forgotten.  Your smile will echo forever."
   -- Ryerson Schwark, to our friend Rob Bernardo.
Newsgroups: comp.software-eng
From: terry@aslss01.asl.dl.nec.com (Terry Bollinger)
Subject: New SCE/Industry Advisory Board
Organization: (Speaking only for myself)
Date: Fri, 18 Dec 1992 20:35:51 GMT

Hi folks,

Just to give you an update on an interesting recent development:

Last week the SEI Joint Program Office formed a new DoD/industry advisory
board for overseeing their Software Capability Evaluation (SCE) program.
The board has four DoD representatives and four industry representatives.

I've had some detailed interactions with some of the figures involved and
am pleased to say that this appears to be a serious, well-thought-out
attempt to bring the software industry into real participation with the
process of applying and using Software Capability Evaluations.  What I
find particularly interesting is that this new committe does not appear
to be just a rubber-stamping committee, as I had feared it might prove
to be when I first heard about it.  There are a number of people involved
who are quite serious about the need for better methods, better reviews,
and better communications all around with regards to SCE.

I look forward to seeing how all of this unfolds.

My only suggestion to fellow motley members of the Net community is that
if some of you out there have been chafing to complain to someone about
being treated unfairly by an SCE or some aspect of the SCE program, *please*
be sure to contact some of these folks when their names are announced.
(No, I am not one of them.)

Even if such things do not directly affect you personally,  you might think
about forwarding this email on to whoever in your organization might be
the most interested or affected.  In short, this might be a good opportunity
to put a little democracy into action, now that the planning and improvement
of the SCE program appears to be opening up a bit.

Up until the formation of this advisory board, those of you who may have felt,
um, a wee bit stepped on have had no real mechanism by which to voice your
concerns about SCE.  Now it appears you will.  As the saying goes: "Use it,
or you may lose it."

				Cheers,
				Terry Bollinger

+--------------------------------------------+-------------------------------+
| Terry Bollinger                            | Phone: 214-518-3538           |
| Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
+--------------------------------------------+-------------------------------+
From: msm@mse.cmu.edu (Mark S McWhinney)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or ju
Date: 13 Dec 92 18:53:12 GMT
Article-I.D.: cs.Bz7oGq.79z.2
Organization: CMU/SEI Master of Software Engineering Program

In article <1992Dec11.180738.28064@spectrum.xerox.com>, 
kirby@xerox.com (Mike Kirby) writes:

> The CMM *is* intended to be a grade.  The Departement of Defense
> established the Software Engineering Institute at Carnegie Mello
> University with the express intent of developing a system by which the
> DOD could "grade" contractors.  

Not true.  The mission of the SEI is to provide leadership in
advancing the state of the practice of software engineering to improve
the quality of systems that depend on software.  Software process
assessments and evaluations provide "grades", but the purpose of
the CMM is to provide a framework for process improvement. 

You and everyone else who comments on the CMM should actually read it
first.  The purpose of the SEI and the CMM is clearly stated on pages
vii and viii of the CMM (CMU/SEI-91-TR-24).  To quote from page viii:
"The SEI's goal ... is to encourage software organizations to focus on
the CMM rather than on the maturity questionnaire [grade]."


Mark

--- standard disclaimers ---
Newsgroups: comp.software-eng
From: julian@vanuliet.unx.sas.com (Phil Julian)
Subject: Re: Request for reuse tool info
Originator: julian@vanuliet.unx.sas.com
Date: Mon, 14 Dec 1992 19:33:24 GMT
Organization: SAS Institute Inc.


In article <2311@sousa.tay.dec.com>, gibian@talent.ljo.dec.com (Marc S. Gibian) writes:
> 
> What I find missing in most CASE tools, and all the time with re-use tools
> and methodologies, is that they are passive.  They require the engineer to
> explicitly search a database, know the ground rules for building designs,
> etc.  I believe that for re-use to realize its very real potential, as
> well as most CASE tools, is for them to become integrated active assistants.
> An example:
> 
> I start by using a design tool to start designing some software.  I would
> like the design tool to not just allow me to build my design, but also to
> constantly try to match portions of MY design against the pool of designs
> (and existing code and tests for those designs).  When it finds a "close"
>match, the design tool points out the match as a candidate for reuse, allowing
> me to evaluate whether it REALLY is a design that does what I need, and then
> incorporates the re-used design into the design I am creating.

I really think that you have found an essential point here, but I
would like to extend the idea of an ACTIVE role to the programmer
himself.  We all need to search for a "design match" for each project
that we do, but this seldom happens even when people work for the same
company or for the same department.

Also, I can anticipate the reaction when you explain your past projects:
   "Oh, I borrowed most of the code and adapted it to my own needs."
   "But, what did you really write yourself?"
   "Well, you don't understand.  I reused the code, which is good."
   "But, can you show me something that you have done yourself?"
   "Well, this part here, and that piece there."
   "Next applicant!"

From this scenario, reuse is bad for resumes.  What do other
programmers or employers value more -- reusing old code or writing
original code?  The problem may be our own attitudes and the attitudes
of the marketplace.  Reuse is not valued as an intrinsic skill.  I
know this is trite, but have you ever seen "reuse" as a desired skill
on a job description?

> --
> Marc S. Gibian			email: gibian@talent.ljo.dec.com
> Principal Software Engineer	phone: (508) 486-6598
> Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100
-- 
 Phil Julian           | "I call it warpabilly, muddle of the rude, queasy
 SAS Institute, Inc.   |  listening!"
 Open Systems R & D    | Rev. Billy C. Wirtz, as quoted in the Record 
 julian@unx.sas.com    | Exchange Music Monitor
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Request for reuse tool info
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 15 Dec 1992 06:48:09 GMT

In article <Bz9Kzo.HAM@unx.sas.com> julian@vanuliet.unx.sas.com (Phil Julian) writes:

>From this scenario, reuse is bad for resumes.  What do other
>programmers or employers value more -- reusing old code or writing
>original code?  The problem may be our own attitudes and the attitudes
>of the marketplace.  Reuse is not valued as an intrinsic skill.  I
>know this is trite, but have you ever seen "reuse" as a desired skill
>on a job description?

There's a good point here, but it is hidden.  There are two important
marketplaces here.  The first is the one that is the end users who
purchase software solutions.  Those people don't give a hoot whether
it is reused code or not--but they do care if it is done quickly,
cheaply and reliably. Reuse may contribute to achieving these goals
which may in turn result in software products that are more attractive
to ultimate consumers. There may be other ways to achieve these goals,
and so while reuse may be a good way, employers may be reluctant to
specify it as an explicit a job requirement and may want to consider
applicants who claim to have other ways of achieving this (i.e. "I'm
just a super coder who turns out 10K/lines of accurate code/day...").

This is, for example, part of SAS Institute's competative advantage,
that they have designed their product in such a way that much of it
can be mounted on a new computer system with just a re-compile, which
makes adding a new system to the support list relatively more
inexpensive, faster and reliable than a ground up port.

The second important market is the employment market.  Engineers are
usually chose by first line managers, who in turn are often more
technically oriented than other managers.  They may figure that ANYONE
can reuse code--and they assume that everyone will be bright enough to
recognize and capitalize on the opportunities to do so.  But after the
reuse is done, there's still the part to be coded, and there the
super-coder looks advantageous.  In reality, many of these assumptions
are at least partially false, and that can lead to the poor results we
sometimes see.

It is also worth noting that one way that "super-coders" often churn
out so much code in a  day is that they are heavy re-users--of their
own past code!  When the programmer is hired, so is her personal
libray of re-useable code. This is vaguely understood in the marketplace but is
one reason that experience with a given OS and language is sometimes
given a lot of weight in hiring decisions, while over all years of
experience are not as strongly rewarded.

-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.



Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: C code Layout
Summary: Read Hot Flaming Code, Ye Raving Commenters
Keywords: C code layout
Organization: :
Date: Sun, 13 Dec 1992 04:48:36 GMT

In article <1992Dec12.122453.8582@seq.uncwil.edu>, herbst@seq.uncwil.edu (R.T. Herbst) writes:
> ...
> My philosophy is to let the language speak for itself. Add comments
> where necessary. Again while directing the efforts of hundreds of
> people on the Safequard Anti-Balistic Missile System, we set standards
> for commenting that let the code be seen. The project met its objectives
> and schedule -- one of the few in that time frame. 

We see this discussion about every two months.  I'm getting tired of
posting my (by now) boring lecture on Efficient and Final causes and
how they have to be tracable in code.  So this time ...

FLAME ON!  (dammit.)

IMO, anyone who hasn't read Kernighan and Plauger's _The Elements of
Programming Style_ (2nd Ed.) has no right whatsoever to speak on this
matter--or to write on it.

FLAME OFF! (sigh.)

> Flame on and damned be he or she who flames out.

Flame out?  Not me ;')
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.software-eng
From: ewoods@hemel.bull.co.uk (Eoin Woods)
Subject: Re: Literate programming in SE
Organization: Bull HN UK
Date: Wed, 16 Dec 92 11:02:43 GMT

kap1@cse.unl.edu (dietrich kappe) writes:

>I'm curious as to whether anyone in the real world is making use of
>literate programming tools (web systems, etc.) as a regular part of
>their development process, and if so, how it fits in with the more
>traditional SE methodologies. What are the pros and cons of this
>approach?
IBM UK labs are using it at the Hursley Lab for CICS development in
conjunction with Z. See Glyn Normington's paper in ZUM 92 proceedings
when they are published next year.

Eoin.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Eoin Woods                         | Tel : +44 442 88-4884 (Fax 4570)     |
| Application Services Product Unit  | BVN : (UK) 773-4884                  |
| Bull Information Systems           |                                      |
| Maxted Road                        | E.Woods@uk03.bull.co.uk              |
| Hemel Hempstead, Herts HP2 7DZ, UK | ...!relay1.uu.net!uknet!brno!ewoods  |
From: paulb@syacus.acus.oz.au (Paul Bandler)
Subject: Value of High Code Coverage Metrics in Testing - Request for Opinion
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Mon, 14 Dec 1992 07:28:12 GMT

I have been tasked with the Quality Assurance of a Product Development.  One of
the metrics I have been asked to measure is the 'Branch Flow Analysis' (BFA)
percentage achieved during unit and system testing.  i.e. How much of the
potential paths through the code is actually excersized during these
testing phases.

I believe we have a tool to measure the %BFA but of course the engineers are
responsible for producing the test cases to excersize the code.

I have 3 questions:-

1)  Do people think that this is a valuable metric?
2)  Is it a cost effective excersize to get engineers to achieve a particular
    %BFA as a completion criteria?
3)  What is a realistic %BFA to aim for?

Please email replies as well as posting as news tends to trickle down here
rather slowly (especially with the Christmas post etc!).

Thanks in anticipation,

Paul Bandler
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Commercial realities of porting (was: Request for reuse tool info)
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 17 Dec 1992 00:22:28 GMT

In article <1992Dec16.185930.18838@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>Never underestimate the value of maintaining source code which compiles
>and runs correctly in many different architectures/environments.  In my
>experience, the best software packages are those that have been rewritten
>after multiple ports to eliminate the last vestiges of non-portability.
>And, if there are bits and pieces which can't port, at least they can
>be identified clearly, isolated, and even coelesced, with many benefits.
>Porting and maintaining your code to/on Sun, DEC, SGI, HP, IBM, Convex ..., 
>and, particularly, Cray, *can* add a tremendous amount to "quality" if the
>process is done with the idea of producing a product which is as clean
>as possible.

I also agree. One of the things I was impressed about in the SAS case
(was true five years ago, don't know if it is still true) is that they
tend to avoid things like #ifdef HP, or #ifdef BSD and instead use ifdef's
based upon services, etc., e.g. #ifdef bigindian, or #ifdef
word-alignment... This style of using #ifdefs tends 
to allow even MORE code to port across an architecture. You just
specify the services that the new platform has once in an include or
make file and then the other service ifdefs just works.  It also
doesn't confuse the code, it clarifies it because it makes it clear
specifically WHAT about an architecture is causing dependencies and
unportable situations.




-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.



Newsgroups: comp.software-eng
From: whg@inel.gov (Bill Gray)
Subject: Re: Is SEI's CMM being used in Anger ...
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Date: Wed, 16 Dec 92 16:59:17 GMT

A search of CBD announcements over the last 18 months turns up 36 references
to the string "SEI".  If anyone is interested,  I'll post a summary of the
particulars of a random selection of these 36 (after weeding out items of
presumed non-interest,  like "Space Exploration Initiative").

========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: C code Layout
Organization: eklektix - Boulder, Colorado
Date: Tue, 15 Dec 1992 07:31:40 GMT

bryant@ced.utah.edu writes:
[good stuff deleted]
>one assignment was to comment the command "strings", which (from the
>distribution) had (if I remember right) ONE COMMENT LINE. I don't know
>who that style works for. Certainly not anyone in the class or the
>instructors.

As noted elsewhere, that's Berkeley and not B'Labs.  OK, I'd find it hard
to believe that strings could get away with one comment.  On the other
hand, I wouldn't think it would need a lot.  Maybe we should drag this out
as an example and look it over?  (It's probably under the UCB copyright,
which is OK.  I'm just thinking that one real example might get us some-
where.)

>i++ vs. i = i + 1? What was that about Gothic cathedrals??

You've lost me.  i++ is a C idiom; i = i + 1 looks wrong in a C program.
How could an uncommon 5-token sequence be better than a common 2-token
sequence?

>>Next, you've got seven lines for a very simple task:...
...
>Again, too wordy for one is not enough for another. The blank lines
>and "gratuitous ornaments" are very much a matter of personal style
>and if used consistantly are fine for me.

Hold on.  We've got something almost objective (sorry) that's being lost
here.  If you have a display window for editing/viewing a file, it's of a
certain rather limited size.  (Even if it were "arbitrarily large", you can
still only effectively see so much.)  There's a cognitive discontinuity:
what you can take in at one glance is far more understandable than what you
have to shuttle back and forth to see.

This is why the difference between one line and seven is far more than "a
matter of personal style", because it may be the difference between being
able to see a unit and having to break it.  It strikes close to what
"overcommenting" means in a practical sense.  It explains some of the
nuances of the "One True Brace Style" (the K&R positioning of braces),
which seeks to minimize wasted vertical space.  It's tied up in many
factors, including the way our natural language is written, but it's real.
-- 
Dick Dunn    rcd@eklektix.com   -or-   raven!rcd    Boulder, Colorado USA
   ...Mr. Natural says, "Use the right tool for the job."
Newsgroups: comp.software-eng