HDTenEightyP/NetNews huggingface dataset:
From: kingsum@ronquil.cs.washington.edu (Kingsum Chow)
Subject: Re: What is Software Design?
Organization: University of Washington Computer Science
Date: 13 Dec 92 15:47:56

>> On Sun, 13 Dec 1992 17:30:30 GMT, feathers@serss0 (Michael Feathers) said:

M> I've just finished reading an article in the latest edition of _The C++
M> Journal_.  The article is named _What is Software Design_ and it was 
M> authored by Jack Reeves.
M> ... (key points omitted) ...
M> All of these are basically changes in perception.  However, one consequence
M> of this change would be the recognition that coding as early in the process
M> as possible is useful.  But this should be no surpise to us, given the shifts
M> that we are seeing toward rapid prototyping and the like.

I find it hard to come to the same conclusion based on your list of key points.
The following seems to be the most relevant key point among the list.

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

But this still does not imply that coding as early as possible is useful.
Coding is a particular instantiation of a possibly more general solution.
Abstractions may be lost from program fragments (ref: Barbara Liskov &
John Guttag. Abstractions and Specifications in Program Development. MIT
Press. 1986. p.5, Fig 1.2)
--
	+-------------------------------------------------------+
	+	Kingsum Chow	kingsum@cs.washington.edu	+
	+-------------------------------------------------------+

Newsgroups: comp.software-eng
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: C CODE LAyout
Date: 14 Dec 92 17:06:15 GMT
	<MARTINC.92Dec11214534@hatteras.cs.unc.edu>
	<1992Dec14.084405@eklektix.com>
Organization: UNC Department of Computer Science
In-reply-to: rcd@raven.eklektix.com's message of 14 Dec 92 08:44:05 GMT

In article <1992Dec14.084405@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:

   martinc@hatteras.cs.unc.edu (Charles R. Martin) writes:
   ...
   >If I read it aright, Herbst "likes a format that leaves the code free of
   >clutter" and therefore prefers to limit in-code comments to only those
   >few setting off the sections, plus some comments on the general meaning
   >of the code.

   I read it somewhat differently.  I understood him to be objecting to
   comments-for-comments-sake.  

That's precisely the reason I phrased it "if I read it aright" of
course.   
   
   I don't see any objection to comments
   describing difficult points, unusual constructs, etc.--although I'm led to
   a feeling that I have, that the way to fix obscure code is to remove the
   obscurity, and that therefore commenting around it is an admission of
   defeat.  Better to comment than to leave it obscure and unexplained, of
   course!

In the device driver I've been writing in my day job, I've just gone
through an exercise of taking my nice clear code and re-writing it
obscure in some essential areas as a performance optimization.  We're
down to that last little bum an instruction here and there phase in an
otherwise working driver.  I would normally agree with you about recode
it clearer, but sometimes you cannot.

   >I frankly have always found it very difficult to believe that anyone who
   >suggests such a style has any professional software engineering
   >experience...

   Let me try to help you believe it.

   I think the first matter is to narrow in on what the real difference is
   between your perspective and Herbst's.  You've obviously been burnt by code
   with inadequate commenting, Herbst by overcommented code.

Rather than continue the point-by-point, let me propose a different
model of the difference: I think the difference is that Herbst's model
is that the difficulty of understanding is a *result* of "too many"
comments ("hiding the code"); mine is that difficulty of understanding
is a result of insufficiently informative comments.  As I said in
passing in an earlier post, I think one of the troubles here is that the
number of comment lines isn't necessarily coupled with how informative
they are.
--
		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
From: mzimmers@netcom.com (Michael Zimmers)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or ju
Date: 13 Dec 92 22:59:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <Bz7oGq.79z.2@cs.cmu.edu> msm@mse.cmu.edu (Mark S McWhinney) writes:

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

I won't speak for the other Mike, but you're confusing the SEI's goal
with the intentions of the Real World [tm].  Yes, it's the SEI's charter
to promote and disseminate technology and methods for better software
engineering, and it's anathema to the academics that the CMM would
be used for such purposes as bidder selection.

BUT

The predecessor to the CMM has indeed been used for that very purpose.
Unless the CMM undergoes a change that makes it impossible (or at least
impractical) to use it for commercial purposes, expect it to experience
the same fate.  The marketplace is desparate and will use whatever is
available if it offers some hope for improvement.
-- 
Michael Zimmers                                    |  Home:  408 996 1984
SoftHelp                                           |  Work:  408 996 1965
Software Solutions for Open Systems                |  Data:  408 996 1974
Newsgroups: comp.software-eng
From: lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE)
Subject: Re: C code Layout
Followup-To: poster
Organization: Universitaet Kaiserslautern FB Informatik
Date: Sat, 19 Dec 1992 10:43:21 GMT


Well I like 
  if (condition) {{ /* hee ha!*/  statement, statement;} ; /* {} */ }

Ok, maybe not.  But seriously:

First, this belongs in comp.lang.c, not comp.software-eng.

Second, the only right style is the one that you or your
group/team/company can agree upon.  Net-wide consensus is
impossible.

Can we drop this now?  Or take it offline into email?

chris...
-- 
Christopher Lott    lott@informatik.uni-kl.de   +49 (631) 205-3334, -3331 Fax
Post: FB Informatik - Bau 57, Universitaet KL, W-6750 Kaiserslautern, Germany
Newsgroups: comp.software-eng
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: System Requirements Specifications
Summary: All requirements presentation styles are not equal.
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Tue, 15 Dec 1992 20:34:15 GMT


David Wood wrote a wonderful article, most of which I heartily endorse.
There are a couple of nits I would like to pick, howerer:

In article 92Dec14000224@cbnewsk.ATT.COM, 
dwwx@cbnewsk.ATT.COM (david.w.wood) writes:
|>There is IEEE 830, DOD 2167A ... and the newer OO presentations such
|>as booch, shlaer-mellor,...  For presenting
|>requirements, any of the above are equal.  

I can't prove it (yet), but I think "the above" are not equal.  Some of
these presentations lend themselves to *proving* that the requirements
are complete and consistent, e.g., Shlaer-Mellor, while others force one
into the position of relying solely on an "informed opinion," aka an
"engineering judgement," e.g., DoD2167A.  I really believe that a
presentation that allows (or encourages) one to prove the requirements
are complete and consistent is superior to one that does not.

MMAG is developing a tool called IADA that provides an executable
simulation of a Teamwork OOA model to prove by demonstration that
the requirements are complete and consistent.



|>the following list is more along the lines of your needs (eh, your
|>requirements you might say):

*LOVE* your list.


|>The top level, system requirements, is to specify requirements on the
|>total system.  The system architecture explains how the requirements
|>are divided into "boxes", allocating and/or distributing requirements 
|>to each box.  

One common flaw I see (in 2167A projects) is that these allocations are
not made cleanly.  All too often a given superior-level
requirements document does not have its requirements written so that an
entire identified requirement, i.e., a unit of text that has its own 
identifier (such as paragraph number), gets allocated to the next lower
level portion of the system.  This leads to *unbelieveable* discussions
of what got allocated to one subsystem and what got allocated to the
"adjacent" subsystem.


|>	system test
|>	system architect
|>	project manager
|>	system designers
|>	integration test)
|>...Make sure you understand the needs of the people
|>who use/need the requirements (they are all EQUAL customers). 

Remember the contractual customer and the system end users, too!



---
-- -- -- --  --
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>

Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: C code Layout
Organization: eklektix - Boulder, Colorado
Date: Thu, 17 Dec 1992 07:46:16 GMT

phardie@nastar.uucp (Pete Hardie) writes:
[I mentioned the "One True Brace Style" (K&R)]
>A brief comment (NPI :->) here.  I find that the brace style:
>	if(condition)
>	{
>		statement;
>		...
>	}
>is more readable than this style:
>	if(condition) {
>		statement;
>		...
>	}
>for one main reason - the alignment of the open and close braces is the same,
>and this (to me) ties the block of code together.  IMHO, this outweighs the
>additional single line per block of vertical space.

This is a real opinion thing.  I've written in lots of languages, including
a lot of C for a lot of years, and I've worked with people with similarly
extensive experience...we sit down and compare notes on style nits, and
this is one point where I *can't* predict how people's opinions will fall!
We can write to such similar styles that we might not be able to tell which
code is whose except for the position of the opening brace.  I think, over
the folks like this that I've met, it comes down ever-so-slightly in favor
of K&R over vertical alignment, but not by enough to call it a win.

I wish we had a way to get some useful objective data on this.  My hand-
wave against the argument Pete presents is that the K&R style has one line
at either end of the bracketed range, rather than two at the start and one
at the end.  Anyway, humans don't pay much attention to the brackets!  We
use indentation.  Don't believe it?  Just try people on something like:
	if (i <= 0)
		mumble = 0;
		return;
In general, if indentation fails to match the real nesting, people will
"see" the nesting (wrongly) implied by indentation.  Also, if you give { a
line by itself, you get the rather stringy
	}
	else
	{
instead of
	} else {
-- 
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
From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: Just how sophisticated should we assume progrr & her/his tools to be?
Summary: i, ii, \<i\>, "_any_" editor can; simple method for simple purpose.
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Wed, 16 Dec 1992 00:40:59 GMT


>Subject: Re: average identifier length (was Comments: Code...)
>Message-ID: <1992Dec15.131302.22615@b30.ingr.com>
>
>>>> >          "i" and "j" are bad loop indices
>>>> No, they're not.                                                     
>>>Yes, they are. 
>>>                 there is a second consideration: searching.  When you
>>>want to see where variable 'i' is used, you are going to get a number of
>>>false hits.  Recommendation: use 'ii', 'jj', etc.
>>
>>If you are using vi to look at your code then you can find all uses of
>>any "word" by specifying your search as \<word\>.                      
>
>So you're going to force everyone to use vi?
>AAAARRRRGGGGHHHH!!!!


This topic was covered a few weeks ago, when _I_ recommended ii,
and got a reply post to the effect that _any_ respectable editor
can do a word search.

So, IMO, the question is, just how sophisticated should we
assume programmers and their tools to be?

Should a person, who wants to find a string, have to know
more than one string search command?

Should anyone who calls herself a programmer 


Regarding the taste in editors:  I chose vi when I found out
that it is on all Unix systems.  Because of that, I haven't 
had to learn a new editor in years, which is a relief.  But
I was using vi for years before I learned (a few weeks ago)
how to do \<i\>.  By the way, \<i\> looks reasonable, because
at least some versions of grep or sed would use that syntax.


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


So, there were at least 3 of us who were using "ii".  I'm not
quite sure how sophisticated  --  e.g.,  \<i\>  --  I want to be;
but lately I've been using "i" because it looks elegant (the i of
the beholder), being the shortest possible name -- one less keystroke,
times # variables times # modules times # programmers.  But I'm
sentimental about "ii".

lehman@ames.arc.nasa.gov
Newsgroups: comp.software-eng
From: john@jlc.mv.com (John Leslie)
Subject: Re: Value of High Code Coverage Metrics in Testing
Organization: John Leslie Consulting, Milford NH
Date: Mon, 14 Dec 1992 20:03:33 GMT

paulb@syacus.acus.oz.au (Paul Bandler) writes:

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

   1) Yes; 2) Yes; 3) 100%.

   Totally untested code should not be let out the door.  If a particular
branch of the code cannot be tested, it deserves to be removed.

   OTOH, maybe you're proposing to enumerate all branches and count the 
combinations of them which have been tested.  This idea is quite useless.
In a modern object-oriented GUI system, the number of possible combinations
exceeds the capacity of today's computers to count.

   There is a middle ground, wherein each branch would be tested in each
"state" of the system.  This sounds very promising to me, but I haven't yet 
seen it done in practice.

John Leslie <john@jlc.mv.com>
Newsgroups: comp.software-eng
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: C Code Layout
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Fri, 11 Dec 1992 23:32:32 GMT

In article 165835@eklektix.com, 
rcd@raven.eklektix.com (Dick Dunn) writes:

|>Scott then talks about noting each change in the source itself:
|>>...Tags were left in the source of the form /*SHB01A.1*/ at each
|>>changed location. It was then quite clear when/why the change was made
|>>and related this to the top line that had this tag...
|>
|>This only works for a little while.  It doesn't scale to longer-term
|>development, because the source code gets so cluttered with these little
|>comments that you really can't understand their relationship any more.
|>...
|>My main point is that it doesn't
|>extend to long-term development...I've actually watched it fail.  Took
|>about a year of relatively active development to make source code nearly
|>unreadable.

But this is exactly what major & minor revision control is all about.
When the number of changes (& associated comments) gets "too large"
(whatever *that* means), you scrub everything into a "major change"
or "major release" and start with a clean slate (wrt changes & their
associated comments).


---
-- -- -- --  --
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>

From: daves@hpopd.pwd.hp.com (Dave Straker)
Date: Mon, 14 Dec 1992 17:43:44 GMT
Subject: Re: C Code Layout
Organization: Hewlett-Packard, CCSY Messaging Centre, UK.
Newsgroups: comp.software-eng

> >
> >On the subject of C CODE layout.
> >I require my students to use the following format. 
>    ^^^^^^^    ^^^^^^^^            ^^^^^^^^^^^^^^^^
> 
> Why in the world would you REQUIRE students to use a particular
> coding style? Coding style is one of the things that makes each
> programmer unique and lends some "art" to this thing we call
> programming!

This highlights an interesting teaching dilemma. Do you enforce
standards or allow individual style? Enforcing standards teaches
something of the 'real world' where you may have to use standards
that you don't 100% approve of. It also meets the objective of
easing communications about programs between lecturer and student
(and maybe even student and student). On the other hand, there
is no 'right' style and it may be wrong to 'lock' students into
a single style where they may later be required to use other styles.

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.


Dave Straker

plug:
(Author of 'C Style: Standards and Guidelines' Pub. Prentice Hall, 1992)

Newsgroups: comp.software-eng
From: kudzu@netcom.com (Michael Sierchio)
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Organization: True Love, and Home-Grown Tomatoes
Date: Wed, 16 Dec 1992 21:02:03 GMT

In article <1992Dec7.090543@eklektix.com> 
	rcd@raven.eklektix.com (Dick Dunn) writes:

>Bugger cause and effect!

Good luck.

>>Quality management is a Level 4 activity, in which quantitative quality
>>goals are articulated and tracked.  It is at this level that the quality
>>of products and projects are controlled...
>
>Heh, heh...so, in the context already established, that most organizations
>are at level 3 or below, you're telling us that we don't really address
>quality until we hit level 4???

No, my post explicitly stated (and the Model states) that being "at" a Level
means engaging in all of the practices that characterize the level.  It is
expected that an org will engage in practices that are "aprt of" higher
levels.

Your claim is that the model does not address the quality of the product,
merely the process.  This is simply false.  The emphasis is on process,
but that is the case in any industry which has instituted Juran's method
of quality.
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
Newsgroups: comp.software-eng
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.software-eng
Subject: what is `code? (was C code layout)
Date: 12 Dec 1992 23:17:01 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

(first a short note on style)

In article <1992Dec11.152310.12726@fcom.cc.utah.edu> bryant@ced.utah.edu
writes:
>... Standards are fine and students should learn that they will probably
>be required to code to standards when they get a real job. Why rob them
>of the LEARNING experience of trying different styles when they are
>students?

If any one teacher decrees a certain style, several others will decree
others or not decree one at all, so this particular complaint seems
unjustified (at least for students for whom programming is a large part
of their coursework---in a `Pascal for Psych Majors' class a single
particular style requirement may have a more lasting effect, and hence
requires more care).

>WHAT! A makefile is NOT CODE.

A makefile certainly *is* code.  The Unix `make' utility is programmed
in a peculiar mix of declarative and imperative operations.  The
declarative sections describe interdependencies (`foo.o may change
whenever foo.c or global.h changes'), and the imperatives are fed to
the shell for processing (`to produce foo.o, execute the following
commands').

(Most `make' clones, including GNUmake and Pmake, have added typical
imperative-language directives, so that one can, for instance, say `for
i in x y z:  declare that $i depends on g and when rebuilding $i use
...' or `if the file ../Makefile.inc exists, read it'.  In a sense this
is a loss: an entirely-declarative language has the advantage of
allowing arbitrary implementation changes.  On the other hand, through
clever use of macros and inclusion, one can now reduce many makefiles
entirely to declarations; the Berkeley net.2 distribution has many
programs whose makefile simply names the program and, if necessary, the
source files.  [The default is to assume that program foo is built from
foo.c.  All C-language inclusion dependencies are derived
semi-automatically.])

One mini-language I created recently consists entirely of declarations,
such as:

	The name `esp' represents a device which
	  attaches to an sbus interface,
	  and provides a scsi interface.
	The code for an `esp' is built from
	  the C source file sparc/sbus/esp.c,

After reading several sets of these files, the `compiler' for this
language emits, among other things, a makefile.  This makefile is still
code, but it is no longer *source* code.  The source is the set of
declarations.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.software-eng
From: aj3u@onyx.cs.virginia.edu (Asim Jalis)
Subject: Re: C code Layout
Organization: University of Virginia, Charlottesville, VA 22903
	<MARTINC.92Dec16111734@hatteras.cs.unc.edu>
	<1992Dec17.081451@eklektix.com>
Date: Thu, 17 Dec 1992 22:26:00 GMT

I prefer the K&R style of using braces with statement blocks:

    keyword (condition) {
        statement1;
        statement2;
        statement3;
    }

Two reasons: 

1.  The closing brace can be matched with the "if", "while",
"for", or "do".  There are so few keywords that it is easy to
form visual associations quickly.  Thus the argument that other
bracing styles make it easier to match braces is not applicable.

2.  The statement block appears physically connected with the
keyword statement.  With styles that leave a blank line between
the conditional statement and the statement block a visual effect
of two distinct objects is produced.  It is easier to visualize
associated code if it appears as a single contiguous object.


Asim.
Newsgroups: comp.software-eng