HDTenEightyP/NetNews huggingface dataset:
From: lfd@cbnewsm.cb.att.com (Lee Derbenwick)
Subject: Re: C code Layout
Organization: AT&T
Date: Tue, 15 Dec 1992 23:24:22 GMT
Summary: Yes, _especially_ comment what isn't there.

In article <KANZE.92Dec15181119@slsvdnt.us-es.sel.de>,
kanze@us-es.sel.de (James Kanze) writes:
[ ... ]
> Again, if you leave out a test for some specific condition because you
> are convinced that that condition can never occur, some comment as to
> *why* you are convinced is in order.
> 
> And any time you use something other than the obvious solution, then
> some comment as to why it wasn't used is in order.  Note that in this
> case, you're actually commenting the code that *wasn't* written.

These are _very_ important points.  They also illustrate the futility
of any fixed comments:code ratio.  "What is the appropriate ratio of
comments to code that isn't there?"

Yet these are the scariest ones:

	/* no test for overflow here; the msg format only has 19 chars */

And then somebody changes the message format.  With the comment, you'll
probably find the error in a reasonable amount of time.  Indeed, having
seen the comment while looking for something else, you are likely to
remember that there's _something_ you've got to change if the message
format ever changes, and you've got a decent chance of locating it before
it becomes an error.

Without a comment like that, lots of luck...

(Of course, you may note that my example comment is a one-liner.  :-)

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd
From: keating@casemo.UUCP (John Keating )
Newsgroups: comp.software-eng
Subject: Re: C code Layout
Date: 17 Dec 92 18:22:22 GMT
Organization: Cray Communications, Inc.

In article <1992Dec15.153859.29057@nastar.uucp>, phardie@nastar.uucp (Pete Hardie) writes:

> A brief comment (NPI :->) here.  I find that the brace style:
> 	if(condition)
> 	{
> 		statement;
> 		...
> 	}

> is more readable than this style:
> 	if(condition) {
> 		statement;
> 		...
> 	}

> However, for some reason, I detest the indention of the braces, like this:
> 	if(condition)
> 		{
> 		statement;
> 		...
> 		}

I prefer the following:
        if (condition)
          {
            statement ;
            ...
          }

This sets both the condition statement and the action statements apart, plus
keeps the braces aligned.

I have no love at all for the second method above (K&R?)

John W. Keating, III
-- 
      John William Keating, III      /-----------------------------------------
 -+=< Cray Communications, Inc. >=+- | If you do something stupid after reading
 formerly: Dowty Communications Inc. | this message, it is your own fault, not
   keating%casemo@mimsy.cs.umd.edu   | mine nor the company I work for.  -me-
Newsgroups: comp.software-eng
From: pjk39593@uxa.cso.uiuc.edu (Jud Kenney)
Subject: change management/issue tracking software
Summary: Looking for Change Management/Issue Tracking software...
Organization: University of Illinois at Urbana
Date: Fri, 18 Dec 1992 21:01:20 GMT
Keywords: change, management, issue, tracking

I am looking for commercial and other software packages that handle change
management or issue tracking for software development.  If you post or e-mail
me information, I will post a summary to comp.software-eng...

Thanks in advance!

-- 
The opinions stated here are my own, and not endorsed by or supported by
the University of Illinois.

pjk39593@uxa.cso.uiuc.edu			Jud Kenney, Student-at-Large
Newsgroups: comp.software-eng,alt.sources.d,comp.sources.d
From: jerry@austin.ibm.com (Jerry Heyman)
Subject: cscope? trus?
Originator: jerry@dcheney.austin.ibm.com
Date: Fri, 18 Dec 1992 20:36:04 GMT
Reply-To: jerry@austin.ibm.com
Organization: IBM AIX AWSD Austin, TX
Keywords: debugging


A user has just approached me asking if we have (or can get access to) a
program called cscope.  It is a file browsing tool which will index and load
files from a given directory and index based on the function names, identify
where it is called and give the use the ability to switch immediately into
that particular file/function call.  I don't know if this is PD or a commercial
product, but if anyone is familiar with this I'd be glad to hear about it.

Also, a program called 'trus' (or something similar) that will monitor a
command and return back a list of each system call that is made, along with
the first couple of arguments to that system call, and the actual return code
from the system call.  Again, I do not know if it is PD or commercial, but if
anyone is familiar with this I'd be glad to hear about them.

you can post here, or I would prefer e-mail to: jerry@austin.ibm.com

Thanks,

jerry
-- 
Jerry Heyman                         e-mail   : jerry@austin.ibm.com
IBM AWSD AIX Dev Env Tools MS 9631    "Software is the difference between
Austin, TX  78758                        hardware and reality"
*** All opinions expressed are exactly that - my opinions and NOT IBM's
Newsgroups: comp.software-eng
From: kudzu@netcom.com (Michael Sierchio)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Date: 17 Dec 92 19:37:23 GMT
Organization: True Love, and Home-Grown Tomatoes

In article <1992Dec17.004510.16996@netcom.com> 
	mcgregor@netcom.com (Scott Mcgregor) writes:

>...But Juran's method doesn't tell you if
>Buick tail fins are more desirable than a boxy European shape, or a
>sweptback Porche shape.
>
>I think the car manufacturers (and other industries) may have a better
>grasp of what people desire in this other aspect of quality, than do
>many software applications providers....

I think we're getting far afield from 'Quality' as opposed to 'qualities' --
The management of requirements is part of the model -- it doesn't tell you
what kind of design methodology to employ.

One of the characteristics of design is that truly great designs cannot be
anticipated by statistical or market research approaches -- or even by
asking "the user", who frequently cannot articulate the requirements, but
knows once they are met (or not).

>But, perhaps because of the youth of the software industry, we feel
>more need to put our attention on these issues than other industries
>do. Until we get at least as good at product judgement as some of the other
>industries, I think some of this attention to identifying what is the
>right product (as opposed to how to produce it right) is very
>appropriate, even though it isn't a focus of CMM or Juran. Wouldn't
>you agree?

I think of Chrysler, just before they almost went down the tubes -- they had
instituted productivity increases that were unheard of in the industry --
they were still building the wrong cars, though.  So, I get your point.
I am just concerned that folks are misrepresenting the CMM, as well as
misusing it.

The real value of the model is to help institutionalize *some* of the
practices that enable "continuous process improvement".  If you use it
to build a state-of-the-art buggy whip factory, well -- I agree, it is
of no avail.

Perhaps I should make it clear that in embracing the model I am not
abdicating my brain by making it my sole source of guidance and inspiration.

-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
Newsgroups: comp.software-eng
Subject: Venugopal, Sarker, Ranananthan reports....
From: Jenny.Rowland@levels.unisa.edu.au
Date: 11 Dec 92 17:24:43 +1030
Organization: University of South Australia

Does anyone know of the following authors (email or Mail address)
or have the following reports?

1. Sarkar, S. and Ranananthan, J. Data Model and Persistent Language
	Features for Integrated Project Support Environments, Ohio State
	University, 1989

2. Venugopal, V. & Ranananthan, J. Programmed Views for Object-Oriented 
	Environments, Ohio State University, 1989

3. Venugopal, V. & Sarker, S. Tool Integration Mechanisms for Database
	Centred CASE Environments,  Ohio State University, 1989


Thanks in advance,
Jenny Rowland

------------
Flinders University of South Australia		University of South Australia
Computer Science				Computer and Informaiton Sc.
Bedford Park					Levels Campus, The Levels
South Australia					South Australia
Australia					Australia

rowland@cs.flinders.edu.au			j.rowland@unisa.edu.au

----------
Chocolate puts every crisis into perspective.
From: jka@windshear.larc.nasa.gov (J. Keith Alston)
Newsgroups: comp.software-eng
Subject: Oracle CASE tool vs Cadre Teamwork
Date: 12 Dec 1992 14:44:02 GMT
Organization: NASA Langley Research Center, Hampton, VA  USA
Distribution: world
NNTP-Posting-Host: windshear.larc.nasa.gov
Originator: jka@windshear.larc.nasa.gov


Hi,
  Anyone out there know anything about the oracle Case tool, and
  how it compares to Cadre Teamwork? Any help would greatly appreciated.
  I'll attempt to monitor this group, but would rather have e-mail.
  
-Keith Alston
-- 
J. Keith Alston jka@windshear.larc.nasa.gov
From: Georg@alpha.saar.de (Georg Edelmann)
Newsgroups: comp.software-eng
Subject: Re: What is Software Design?
Date: 19 Dec 92 17:49:51 GMT

Hi Michael,

feathers@serss0 (Michael Feathers @ Florida International University, Miami) once wrote....
>
>I've just finished reading an article in the latest edition of _The C++
>Journal_.  The article is named _What is Software Design_ and it was
>authored by Jack Reeves.
>
>The ideas that he presents confirmed my suspicions about some of the problems
>that we currently have in software engineering.  I whole-heartedly suggest
>that anyone who can find the article do so and read it.
>

If this article consists in a digital form, please post it.

My comments upon your points mentioned :

>-There are some key differences between developing hardware and developing
> software.

I am nor quite sure. See later comments.

>-For a meaningful parallel between hardware and software development to
> exist, the coding of software should be considered part of the design process.

Not at all. For me producing HW equals to coding.

>-Software is produced through the process of compiling and linking.  This is
> a rather low cost in comparision with the cost of design.

See above

>-Engineering designs must be complete so that production can be carried out
> successfully.

Thats not realistic. Even the HW engineer often needs some iterations.
Dont forget about the HW redesigns. My last project had four of them.

>-The only document developed when software is designed that can be considered
> this complete is the source code.

False. At the end of SW design is the Structured Chart (compare it to
the HW schemes)

>-Testing and debugging are part of the design process.  "they are the software
> equivalent of the design validation and refinement processes of other
> engineering disciplines."

You are right when you mean "debugging the design" equals to "Design reviews"

>-"There are other design activities - call them top level design, module
>  design...  A good software design process recognizes this and deliberately
>  includes these steps."
>

I agree.

Very interesting. Lets follow up the discussion.

cu

Georg
----
Georg Edelmann                                  Telephone: 049-7643-8807
georg@alpha.saar.de                             Address:   Dragonerstrasse 47
                                                           D7834 Herbolzheim 4

Newsgroups: comp.software-eng
From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: Re: User interface quality definition (what do you think?)
Summary: A brief opinion.
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Fri, 11 Dec 1992 19:31:29 GMT

>= Jean-Francois Martin                                     martin@dmi.usherb.ca=
wrote:
>Question: For you, what means "User Interface Quality"? 
...
>Thanks for people who responded so far   (3 responses only).

User interface quality is unobtrusiveness, allowance of dissection,
and ability.

I've sent you an email message with more details.

lehman@ames.arc.nasa.gov
From: lagemaat@cs.utwente.nl (Jeroen van de Lagemaat)
Subject: Re: Value of High Code Coverage Metrics in Testing - Request for Opinion
Organization: University of Twente, Dept. of Computer Science
Date: Tue, 15 Dec 1992 08:24:07 GMT

In article <1992Dec14.072812.13689@syacus.acus.oz.au>, paulb@syacus.acus.oz.au (Paul Bandler) writes:
|> 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 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?
|> 
....
|> 
|> Paul Bandler


The approach seems usefull nice and we used a similar one in our paper:
"A Formal Aprroach to Conformance testing, IWPTS 90" with the following
modification of attributing traces (actually a test) with a cost function.
Some traces are more critical than others.

I would not mix up the work of engineers and testing. Of course engineers do 
there own part of testing/debugging, The main disadvantage is that during
construction of the system a complete and corrrect system needs to be build.
Not a system which passes 90% of the tests, since the tests may be wrong too.

Realistic %BFA, seems to depend on field of application of the system,
the quality of the tests, the available resources etc.



-- 
    ___
 __/   \__________  Jeroen van de Lagemaat    <lagemaat@cs.utwente.nl>
|  \___/          |         
|___     __   ___ | University of Twente     
| |  |  /  \ (__  | Tele-Informatics & Open Systems
| |__|__\__/____) | P.O. Box 217  NL-7500 AE Enschede  The Netherlands
|_________________| tel. +31 53 893684              tfx. +31 53 333815

                    Humour, you're making me laugh.
                                    - Herman Finkers, Dutch comedian -

Newsgroups: comp.software-eng
From: dws@menlo.cadre.com (David W. Smith)
Newsgroups: comp.software-eng
Subject: Re: Software Inspections.  How many does it take?
Date: 18 Dec 92 19:02:21 GMT
Article-I.D.: menlo.1992Dec18.190221.16549
Organization: Cadre Technologies Inc., Menlo Park Operation

In article <1992Dec17.232054.8942@eecs.nwu.edu> Travis Marlatte responds
to Doug Gray's contention that the author should be "as distanced as
possible from the review"

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

It may be important to have authors participate in reviews, but one goal of a
review may be to see how well the code stands up on its own.  If the author is
actively involved in explaining the code, this goal may not be well met.  And,
IMHO, the more active the author, the more likely egos will come into play,
turning the review into a defense of the work from perceived attacks.

Authors can present historic background in a pre-review briefing sessions,
as it may help the reviewers understand the work they're preparing to read.
Taking time during reviews to explain reasoning detracts from the purpose
of the review.

The deeper advantage of having authors be passive in reviews, called on only
to help get the team past sticky points, is that authors will (hopefuly) turn
their attention more toward preparing a quality piece of work to be reviewed
than towards girding their egos for battle.  The knowledge that I may have to
sit quietly while someone else reads through and explains my code at a review
is a strong motivator to keep my act clean.

-- 
Dave Smith, Cadre Technologies Inc. - Database Tools Division
4500 Bohannon Drive, Suite 150, Menlo Park, CA  94025
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: C code Layout
Date: 19 Dec 92 18:42:16 GMT
	<1992Dec17.081451@eklektix.com> <1992Dec18.063344.8617@netcom.com>
Organization: UNC Department of Computer Science
In-reply-to: mcgregor@netcom.com's message of 18 Dec 92 06:33:44 GMT

In article <1992Dec18.063344.8617@netcom.com> mcgregor@netcom.com (Scott Mcgregor) writes:

   In article <1992Dec17.081451@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
   >The point of that long ramble is that if you've got code with lots of
   >detailed comments, you can push past a hardware barrier to displaying it,
   >but you'll still run into eye/brain limits.  THOSE limits--our mental and
   >physiological limits--we have to take into account when writing code.

   This point is right on.  And once you realize this, you realize that
   once you hold the choice of language constant (e.g. standard C code
   conventions) you've strongly limited the freedom to get bigger chunks.
   That's one of the reasons I was very interested in the alternate
   schematic representation of the code, which resulted in a more
   efficient horizontal usage without apparent increase in cognitive
   load. The net result is that more could be understood in a glance.

   I think that applying these principles WITHIN the restrictions of a
   given language is entirely appropriate and should be done. But I don't
   think we should allow ourselves to get so comfortable with these
   restrictions that we don't push at the envelope and get some more
   freedom from time to time.

Ditto -- sorry to agree with you in a secondary step, Dick, but I know
you'll understand.  I think what's *really* important isn't the amount
of comments (although I still feel it's too risky for a professor to
chide people for too many comments!) but the amount of information
that's being conveyed. 
--
		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: janzen@lichen.mpr.ca (Martin Janzen)
Subject: Re: metamodels, metalanguages, templates, domain models ...
Reply-To: janzen@mprgate.mpr.ca
Organization: MPR Teltech Ltd.
Date: Wed, 16 Dec 92 21:07:34 GMT

In article <1992Dec16.001309.593@ide.com>, biesty@ide.com (Bill Biesty) writes:
>In article <1992Dec15.191917.1072@mprgate.mpr.ca> janzen@mprgate.mpr.ca writes:
>[...]
>>6) mixin classes
>
>I've never heard of this one. Could someone fill me in?

Sure!  A "mixin" class is one that's intended to be used as a base
class in order to add particular abilities to its derived classes.
In other words, you "mix in" the new abilities into the derived classes.
Using multiple inheritance, you can create some pretty sophisticated
derived classes simply by combining several mixin base classes.

For example, in order to implement the Model-View-Controller paradigm,
you could create a "Model" mixin, which adds to a derived class the
ability to maintain a list of Views, and to notify the Views that they
are to update themselves.  In C++, it might look something like this:

    class Model
    {
      public:
	virtual ~Model();
	virtual void attachView(View *);
	virtual void detachView(View *);
	virtual void updateViews(void) const;
      protected:
	Model(void);
      private:
	View **       _view_list;
	unsigned int  _num_views;
	unsigned int  _alloc_views;
    };

Similarly, a View mixin adds to a derived class the ability to attach
itself to a (subclass of) Model, and to receive update notifications
whenever its associated model has changed:

    class View
    {
      public:
	virtual ~View();
	virtual void updateView(void) = 0;
      protected:
	View(Model &);
      private:
	Model &_model;
    };

Of course, you now have to provide some useful updateView() behaviour
specific to your derived class.

For more examples, take a look at the design of the Eiffel libraries.

-- 
Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
MPR Teltech Ltd.                  Phone: (604) 293-5309
8999 Nelson Way                   Fax: (604) 293-6100
Burnaby, BC, CANADA  V5A 4B5
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: C code Layout
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 18 Dec 1992 06:54:08 GMT

Related story:

Back in the mid-late 70's I was consulting on a project.  Part of this
involved reviewing code that had been written by an outside contract
firm. These programs were written in statement oriented (as opposed
to line oriented like BASIC, FORTRAN, and COBOL) languages like C,
Pascal and PL/I . The people who had written this had run a special
filter on the programs. These filters removed all the comments, and
also all extra white space (tabs, repeated, or unnecessary spaces).
Also, all variable names were two characters long, e.g. i1, i2....

When I complained that I was having a hard time reading these "text
flowed" programs, the author just suggested that I write a pretty
printer program that reformatted them in a way that I liked (like one
statement per line, with indentations, etc.) I pointed out that with
the two character variable names and comments stripped out that it
would still be hard, but the author claimed that an algorithm is
independent of the variable names chosen and should be deducable even
without comments. 

I finally asked why the author even bothered to write this
reformatting program and use it.  He answered that he had been used to
programming very small computers for industrial controllers and that
this was a trick he learned--he realized that stripping the comments,
keeping the variable names short, and removing white space would save
the parser of the compiler from having to spend time processing
semantically non-meaningful components would make the compile take
less time.  This was therefore more efficient.

While I couldn't disagree with his efficiency claim, I wasn't sure
that he was maximizing the right resource. Especially since this
wasn't compiled on  a slow and limited controller, but a DEC 10, which
was rather powerful for the day.

I've never seen views so extreme since, but I've heard many similar
arguments that bring this experience to mind from time to time.


-- 

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