Language Choice and Coding style

Language Choice and Coding style

[Nasser Abbasi]

Tonight I'd like to ask a question I've always been afraid to ask.

I'd like to know why do C and C++ programmer 

pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 

Write_In_Clear_And_Nice_Way_Like_This ??


Is this a cultural thing? I don't want to get into case sensitive
or not case senstive issue here, since I don't see why this way of
writing has anything to do with it.

My own personal analysis of the situation after long thought is that 
it is a cultural thing.  

Most  C and C++ programmers are more hippy , 1960's type, type of people,
the anti-establishment crowd, who just want to be different, and so 
they adjust the code more so by WritingItLikeTHis so that the unique
personality of the C/C++ programmer comes out in distinctive way from
the rest of the programmer community at large.

While the Ada programmers seem to be more of the conservative type, 
the type who would never go faster than 55 mph even in the middle of dead 
valley where there is no traffic for miles on stretch, the type who
would never color their hair or do something anti-establisment and so
this reflect in the Long_And_Slow_But_Sure_Way_They_Write_The_Code.

I must admit that I myself, on a bad day, when I am mad about something,
(like a bug that is hard to find) that IdoStartWritingLikeThisAndRightlySo, 
but most days I_Like_To_Write_Like_This, and my code as a result is very 
easy to read.

I don't think I've seen Ada code written the C/C++ way, and I dont
think I've seen C/C++ code writeen the Ada way. I've seen code
written like_this_with_no_upper_case which is C/C++ code, but that
was very rare. 

SO, why do you think this difference exist between the 2 groups of
programmers? It seems to be getting worse with time. I remmember
starting to first see ThisTypeOfWritingOfCode around 1985-1986 time
frame, I dont think I saw this before but I can be wrong. So the 
question is really, what did happen in 1985-1986 to cause this?

It can't be just a random thing. This time frame seems to coinside
with C++ becomming more populare and starting out, but there is
nothing in the C++ language manual that SaysOneMustWriteLikeThis , and
also there is nothing in the Ada manual that says one Must_Write_Like_This,
so what is the deal here?

I'd like to research this further and find out how do Cobol and PLi and
Basic and other programmer write, and see if there is a correlation
between the emotional/cultural profile of the programmer and between
the tyep of the language they use and the manner of which they write
in it.

Well, thank you in advance for your opinion on this subject.
nasser




-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)

Re: Language Choice and Coding style

[Giuliano Carlini]

In <nh3f3pppsl.fsf@paralysys> nasser@apldbio.com (Nasser Abbasi)
writes: 
>
>
>Tonight I'd like to ask a question I've always been afraid to ask.
>
>I'd like to know why do C and C++ programmer 
>
>pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers

>Write_In_Clear_And_Nice_Way_Like_This ??
>
>Is this a cultural thing?

Yeah it is.

>Most  C and C++ programmers are more hippy , 1960's type, type of
people,
>the anti-establishment crowd, who just want to be different, and so
> 
>While the Ada programmers seem to be more of the conservative type, 
>the type who would never go faster than 55 mph even in the middle of
dead 
>valley where there is no traffic for miles on stretch, the type who

But, not in this way. I've seen both "hippies" and "straights" using
both
languages. In fact a C++ programmer who wanted to be different
Would_Write_Like_This
because no other C++ programmers do. TheyWriteLikeThis for the same
reason that
Ada programmers Write_Like_This.

They both follow the conventions which existed when they started
programming in that
language. C++ programmers adopted the Smalltalk style. I believe the
Smalltalk style
came from following the Simula style. Ada programmers followed the
Pascal style who
I believe had followed the Algol style. These styles started in
different places in
different times by different people, so it isn't surprising that two
different styles
were created. And given that people tend to adopt what has come before,
it is normal
that they both still exist today in two different domains which don't
interact much.

Personally, I prefer Reading_Identifiers_Like_This. But I adopt the
convention of the language
I'm writing in. To do otherwise would silly.

g

Re: Language Choice and Coding style

[David Weller]

In article <nh3f3pppsl.fsf@paralysys>,
Nasser Abbasi <nasser@apldbio.com> wrote:
>
>Tonight I'd like to ask a question I've always been afraid to ask.
>
>I'd like to know why do C and C++ programmer 
>
>pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 
>
>Write_In_Clear_And_Nice_Way_Like_This ??
>
>

From the original C documentation (which was unpublished until a rogue
copy escaped a few months ago):

Section 2, para 4:
	Usage of white space in identifiers is not recommended.
	To ensure no white space is used, the underscore symbol,
	'_' consumes 64kb of symbol space per occurrence.  The
	occurrence of a lower case and upper case letter together,
	however, consumes less than their sum -- 4 bits exactly.



:-)  
-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Language Choice and Coding style

[Robert Dewar]

Nasser asks

"SO, why do you think this difference exist between the 2 groups of
programmers? It seems to be getting worse with time. I remmember
starting to first see ThisTypeOfWritingOfCode around 1985-1986 time
frame, I dont think I saw this before but I can be wrong. So the
question is really, what did happen in 1985-1986 to cause this?"

This style of separating words with upper case and no break characters
is I think derived from the Pascal world (for example it was the UCSD
style). Micrsoft derived much of their standard interfaces from this
world, as of course did Borland, so I suspect the importation of this
style into C++ comes from this source).

Re: Language Choice and Coding style

[Dr. John B. Matthews]

In article <dewar.835406503@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Nasser asks
> 
> "SO, why do you think this difference exist between the 2 groups of
> programmers? It seems to be getting worse with time. I remmember
> starting to first see ThisTypeOfWritingOfCode around 1985-1986 time
> frame, I dont think I saw this before but I can be wrong. So the
> question is really, what did happen in 1985-1986 to cause this?"
> 
> This style of separating words with upper case and no break characters
> is I think derived from the Pascal world (for example it was the UCSD
> style). Micrsoft derived much of their standard interfaces from this
> world, as of course did Borland, so I suspect the importation of this
> style into C++ comes from this source).

Apple was one of the first to license UCSD Pascal from the
university regents (Softech was the other). At that time, the Apple
II was upper-case only, and the mixed case style wasn't apparent in
Apple code until the the advent of the Apple //e in 1981, with its
full upper & lower case keyboard and display. The style was firmly
entrenched in the original object oriented Pascal derivative,
Classcal, and the early Mac Pascal compilers by 1983. The Inside
Macintosh books of 1984 show the mixed style throughout: init cap
for units (packages), procedures and functions; init lower for
constants and variables. Microsoft, one of the largest early Mac
developers after Apple, adopted the style (along with interface:-)

The style clash became singularly apparent when we began writing
bindings and porting sample code to the Mac/MachTen implementation
of GNAT. The only thing many adherents of one style or the other
can agree on is that mixing the two is worse:-)

John
----------------------------------------------------------------
Dr. John B. Matthews
jmathews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"

Re: Language Choice and Coding style

[The Amorphous Mass]

On 21 Jun 1996, Nasser Abbasi wrote:

> 
> Tonight I'd like to ask a question I've always been afraid to ask.
> 
> I'd like to know why do C and C++ programmer 
> 
> pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 

  Except for the "Hungarian notation" silliness, the idea of 
spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal 
idiom, and it has become nearly universal in GUI libraries (again I 
think because of Smalltalk's influence).  C programmers use variable names 
like x, i, p, fp, str. :-)

> Write_In_Clear_And_Nice_Way_Like_This ??

  I have seen that as well.  That's a common unix programming idiom 
(except_that_the_names_are_often_all_lowercase) that can be found in the 
Standard C environment as well.

> Is this a cultural thing?

  I think it's a precedent thing.  The practice of squashingWordsTogether 
is firmly established in some camps, and newcomers are exposed to it and 
pick it up.  Th prct of abbr evth is cmn in oth cmps, and newcomers there
pick it up, etc.  If your first book was Learn C on the Macintosh (whose 
has a Pascal-based interface) thenYouProbablyBelongToTheFirstCamp.  If your 
first book was K&R, u prb blng to oth cmp.  If you leaned on a PC, 
vndjskaThen jkuidsYou ksldjfBelong jdtd84To zxThe nmdsadHungarian ncmqCamp.

/**James Robinson***********************            
  "If a fatal error occurs, the program should not be allowed to continue."
 -- Oracle Pro*C User's Guide         *************james-robinson@uiowa.edu**/

Re: Language Choice and Coding style

[Robert Dewar]

James said

"  Except for the "Hungarian notation" silliness, the idea of
spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal
idiom, and it has become nearly universal in GUI libraries (again I
think because of Smalltalk's influence).  C programmers use variable names


I really think this is Pascal influence rather than Smalltalk influence,
since it predates the Smalltalk craze. Remember that Pascal had an
out-of-proportion influence on PC's because of Turbo-Pascal. The Microsoft
interfaces, on which many C programmers grow up, are Pascal derived (they
even used Pascal calling sequences, and needed special treatment from C
to get the calling sequence right). As I said in an earlier message, I
trace the StyleOfSmashingWordsTogetherWhichIDoNotLike to UCSD Pascal.

P.S. When using the default file names in GNAT, this style really is
unpleasant, since the default file names are all lower case (thankyou
Unix for being so particular about casing of file names :-) and you
get a file name like styleofsmasgingwordstogetherwhichidonotlike.ads
which is really charming :-) [of course you can always use the
Source_File_Name pragma to specify a non-default file name]

In an earlier note, someone (perhaps tongue in cheek) suggested that
the reason that this style is popular is that programmers are too lazy
to press the shift key and reach for the underline. It's hard to believe
that coding styles could be significantly affected by such silliness
but who knows?

Re: Language Choice and Coding style

[The Amorphous Mass]

On 23 Jun 1996, Robert Dewar wrote:

> James said
> 
> "  Except for the "Hungarian notation" silliness, the idea of
> spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal
> idiom, and it has become nearly universal in GUI libraries (again I
> think because of Smalltalk's influence).  C programmers use variable names
> 
> 
> I really think this is Pascal influence rather than Smalltalk influence,
> since it predates the Smalltalk craze. Remember that Pascal had an
> out-of-proportion influence on PC's because of Turbo-Pascal. The Microsoft
> interfaces, on which many C programmers grow up, are Pascal derived (they
> even used Pascal calling sequences, and needed special treatment from C
> to get the calling sequence right). As I said in an earlier message, I
> trace the StyleOfSmashingWordsTogetherWhichIDoNotLike to UCSD Pascal.

  The MacOS interface usesThatConventionToo, yearsBeforeWindowsWas 
Released, and although the Mac used Pascal calling conventions as well, 
it is well known that the designers of MacOS borrowed heavily from Xerox 
PARC.  Since the Pascal I learned used very standard-looking variable 
names, and since both the Mac Toolbox and the Smalltalk class library 
useTheMashedTogetherIdiom I figured that it must be a Smalltalk thing, 
and subsequent GUI libraries borrowed either from MacOS (including its 
Pascal interface -- apparently Pascal calling conventions make the OS's 
life easier?) or from Smalltalk.

> P.S. When using the default file names in GNAT, this style really is
> unpleasant, since the default file names are all lower case (thankyou
> Unix for being so particular about casing of file names :-) and you
> get a file name like styleofsmasgingwordstogetherwhichidonotlike.ads
> which is really charming :-)

  Yummy.

> In an earlier note, someone (perhaps tongue in cheek) suggested that
> the reason that this style is popular is that programmers are too lazy
> to press the shift key and reach for the underline. It's hard to believe
> that coding styles could be significantly affected by such silliness
> but who knows?

  It would explain the prevalence of code filled with variable names like 
x, i, n, t, c, ...

--
James Robinson            "Because we are returning a copy for postfix ++ 
james-robinson@uiowa.edu  expressions, statements such as (c++)++; won't
robinson@cs.uiowa.edu     work as expected."            -- Weiskamp & Flamig,
                                           _The_Complete_C++_Primer_, 2nd ed.

Re: Language Choice and Coding style

[Adam Beneschan]

In article <dewar.835537168@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
 >James said
 >
 >"  Except for the "Hungarian notation" silliness, the idea of
 >spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal
 >idiom, and it has become nearly universal in GUI libraries (again I
 >think because of Smalltalk's influence).  C programmers use variable names
 >
 >
 >I really think this is Pascal influence rather than Smalltalk influence,
 >since it predates the Smalltalk craze. Remember that Pascal had an
 >out-of-proportion influence on PC's because of Turbo-Pascal. The Microsoft
 >interfaces, on which many C programmers grow up, are Pascal derived (they
 >even used Pascal calling sequences, and needed special treatment from C
 >to get the calling sequence right). As I said in an earlier message, I
 >trace the StyleOfSmashingWordsTogetherWhichIDoNotLike to UCSD Pascal.

UCSD Pascal had a TURTLEGRAPHICS package for teaching graphics to
beginning programmers.  (We called it TURKEYGRAPHICS because it
gobbled up memory.)  It was very simple conceptually; you could move a
cursor around the screen, and you had a "pen" that you could raise or
lower--if the pen was down, moving the cursor would cause lines to be
drawn along the screen.

Lore has it that the UCSD Pascal code for TURTLEGRAPHICS had a Boolean
variable that would, in Ada, be written as Pen_Is_Down.  Another
variable was called Go_On.  Neither one looks very appealing when
written in all-capital letters with no underscores.  This might have
been one reason UCSD adopted the smashed-together mixed-case style
(also called "pseudo-Germanic", probably because the German language
sometimes forms nouns by smashing several words together).  This was
the best they could do, since Pascal doesn't allow underscores in
identifiers (UCSD Pascal actually did, but it was a non-standard
extension nobody used).

                                -- Adam

Re: Language Choice and Coding style

[Peter Hermann]

Adam Beneschan (adam@irvine.com) wrote:
: Lore has it that the UCSD Pascal code for TURTLEGRAPHICS had a Boolean
: variable that would, in Ada, be written as Pen_Is_Down.  Another
: variable was called Go_On.  Neither one looks very appealing when
: written in all-capital letters with no underscores.  This might have

I wonder why people expose themselves to extra work.
Since a couple of years I even quit typing capital letters at all.
In former days I believed that typing the keywords in a different
style, for textbook purposes, but I have changed my mind: no big win.
It is much more comfortable to ignore the shift key on the keyboard.
What a blessing that Ada allows this!
If Ada had the Unix/C-malady of case-sensitivity
(imho a non-professional academic joke)
I never had accepted Ada, anyway, right from the beginning.
And I would reject an text editor which does not have 
the non-case-sensitive search function as default.

I made the experience that lower case letters are faster to read.

: been one reason UCSD adopted the smashed-together mixed-case style
: (also called "pseudo-Germanic", probably because the German language
: ( sometimes forms nouns by smashing several words together).  This was

We Germans are used to easily read combined nouns such as "pseudogermanic".
We even do not need a hyphen between the subcomponents when reading
"Adacompiler", "Gnatlinker", "Compilermanufacturer", etc..
Nevertheless I am a strong advocate of heavy use of underscores.
Therefore I would prefer e.g. turtle_grafics, pen_is_down, go_on, etc.
in "programcode" ;-).

for one thing i have an extreme antipathy:
the enforcement of rules which do not have a useful justification.
if someone chooses for himself to carve all in CAPS, he may
freely do so, but he should not bother me to request this from me.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Language Choice and Coding style

[Robert A Duff]

In article <4r059t$2at0@info4.rus.uni-stuttgart.de>,
Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>for one thing i have an extreme antipathy:
>the enforcement of rules which do not have a useful justification.
>if someone chooses for himself to carve all in CAPS, he may
>freely do so, but he should not bother me to request this from me.

Software "engineering" is the only engineering discipline I know of
where the practitioners commonly take this "cowboy" attitude -- "you can
do things however you like; just let *me* do things *my* way."  It works
OK on one-person projects, but as soon as two or more people have to
work together on the same program, it's a disaster.

There's no "useful justification" for making everybody drive on the
right-hand side of the road, either.  But there *is* a useful
justification for making everybody drive on the same side of the road.

- Bob

P.S. I agree that the ALL_CAPS style is ugly.

Re: Language Choice and Coding style

[Samuel Mize]

In article <Dtprq5.4Dr@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <4r059t$2at0@info4.rus.uni-stuttgart.de>,
>Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>>for one thing i have an extreme antipathy:
>>the enforcement of rules which do not have a useful justification.
>>if someone chooses for himself to carve all in CAPS, he may
>>freely do so, but he should not bother me to request this from me.
>
>Software "engineering" is the only engineering discipline I know of
>where the practitioners commonly take this "cowboy" attitude -- "you can
>do things however you like; just let *me* do things *my* way."  It works
>OK on one-person projects, but as soon as two or more people have to
>work together on the same program, it's a disaster.

This is true, and in keeping with Ada/Software Engineering philosophy.

(A lot of hackers call themselves "software engineers" -- they're
as truly "engineers" as are "sanitation engineers."  There are also
people really trying to create an engineering discipline, and have
been for decades.)

Anyway, for this particular small area -- code formatting -- the best
approach is to use a formatting editor, so everybody can set up his
*own* preferences and see the code the way *he* finds most readable.
(Or she.)

Samuel Mize

Re: Language Choice and Coding style

[Robert Dewar]

Samuel says

"Anyway, for this particular small area -- code formatting -- the best
approach is to use a formatting editor, so everybody can set up his
*own* preferences and see the code the way *he* finds most readable.
(Or she.)"

I strongly disagree. In theory this sounds OK, but style covers much more
than simple rules that can be messed around with by a formatting editor.
If a team is not willing to agree on unimportant little things, but insists
on going their own individual way, I think you have little hope of 
achieving a high degree of coding style consistency, something I think
is vital for the success of software projects with more than one person
involved.

Re: Language Choice and Coding style

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

<..snip..>

>I strongly disagree. In theory this sounds OK, but style covers much more
>than simple rules that can be messed around with by a formatting editor.
>If a team is not willing to agree on unimportant little things, but insists
>on going their own individual way, I think you have little hope of 
>achieving a high degree of coding style consistency, something I think
>is vital for the success of software projects with more than one person
>involved.

This all really depends on how you define "coding style" and where you
consider code formatting to be a particularly important part of that. 

Personally I consider "coding style" to mean how things are done
rather than the way they look. If I can give an example of one style
compared to another (from C as it is a very obvious and common one):

	a = ((x < 0) ? y : z);

and

	if (x < 0)
	{
		a = y;
	}
	else
	{
		a = z;
	}

are two ways of doing the same thing, but using what I consider to be
different coding styles.

The point is, there can be many different and equally valid ways of
producing e.g. an algorithm code. No one can say they know the best
way of doing it, so why should they enforce a style that they are
comfortable with? Not only could that lead to inefficient code, but
allowing coders more freedom to do things the way they want to is also
likely to be a learning experience for the others in the team.

Code formatting on the other hand is a very mechanical thing and can
be easily modified by machines into a format that a coder feels most
comfortable with. I find that as long as code looks the same (in terms
of formatting), then someone else's style of coding becomes much
easier for me to understand.

I would therefore consider a comfortable format of code to be far more
important for maintenance purposes than enforcing a particular style,
and if machines (by way of formatting editors) can help in this then
it should be actively encouraged.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Peter Hermann]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: I strongly disagree. In theory this sounds OK, but style covers much more
: than simple rules that can be messed around with by a formatting editor.
: If a team is not willing to agree on unimportant little things, but insists
: on going their own individual way, I think you have little hope of 
: achieving a high degree of coding style consistency, something I think
: is vital for the success of software projects with more than one person
: involved.

IMHO, you are going a bit too far.
I had to manage implementations on every existing (reasonable) hardware
of 2 very large Fortran-systems with contributions of more that 2 dozen
people, approx. 100 people over the time, of course.
For consistent development of code I wrote a "Fartran harter Standard"
(oh, nice typo :-)  "Fortran harter Standard", of course.
In this guide, all contributors were obliged to follow a lot of rules.
People hated me first but later on they were grateful when they saw
that we had (nearly) push-button installations on different systems.
With the appearance of Ada I recognized that we would not have more the 
need to impose extra rules on our own, a really great advantage.
Because: Every rule which can be dropped is a good rule.
The fewer rules we have the greater the acceptance.
I hate it to impose rules.  In Ada this is very possible. 
In Ada nobody can escape the useful language rules without being
punished by rejection  (how practical ;_).
I like it to allow everyone to show his personal style.
This is even important because the motivation is very much higher.
They are and should keep to be individuals.
And I like it when I see at first glance "Oh that is the typical 
style of Barbara". This holds for code production inside bodies.
If a team agrees on a specific shape of the interfacing stuff,
this must be accepted by the whole team. Agreements of that kind
can then be carried by everybody in the team (then they really like it).

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Language Choice and Coding style

[Robert Dewar]

Peter Herman says

  "I like it to allow everyone to show his personal style.
  This is even important because the motivation is very much higher.
  They are and should keep to be individuals.
  And I like it when I see at first glance "Oh that is the typical
  style of Barbara". This holds for code production inside bodies."

Fascinating to see this point of view expressed so directly (it is I am
sure shared in practice by many programmers).

To me this "ego-centered" style of programming is deadly. It promotes a
situation where in a big project code is owned by individuals. Clearly
if you see that some code is "typical Barbara" style, then the next step
is that only Barbara touches that code, and a consequence is that only
Barbara really looks at that code.

This is not team work, this is a collection of individuals working together,
and you lose the advantages of working as a team. In particular:

   a) If Barbara starts polishing her resume, you can be in big trouble
   b) Only one pair of eyes looks at Barbara's code (other people don't
        because they have their own style they prefer to read).

Furthermore, anyone maintaining the system will find a collection of
different styles that will make it much harder to understand what is
going on.

It's certainly interesting that in the GNAT project, we work hard to achieve
the exact opposite of what Peter regards as acceptable or even desirable.
We work to get complete consistency of sources. This is partly done by
automatic tools (try turning on the -gnatg switch sometimes), and partly
by following a set of standards, which are then informally enforced by
modifications being read by multiple people. You absolutely cannot tell
who wrote code from its style, and indeed we strongly discourage the notion
of authorship (we never for example attach names to units). Sure in practice
certain people know certain code well and our informally the experts in
particular areas, but if you look at the revision histories, you will see
that all sorts of people work in all parts of the system.

In Peter's view of the world, I have too often seen the kind of code
ownership where the owner of the code resents anyone else looking at
their code, let alone modifying it. In GNAT, we strive for and generally
achieve an environment in which your reaction to someone fixing a problem
in code that you wrote is "great, one problem that *I* don't have to fix!"

As for motivation, I think Peter is quite wrong there too. We agree up
front to work as a team. We decide style rules by a vote, but once the
vote is taken that's that. Sometimes it takes a bit of time to get used
to rules. For example, I used to always WRITE_MY_IDENTIFIERS in Ada 83
upper case style (which was the Alsys coding standard), but everyone
else on the team preferred to Write_Their_Identifiers_This_Way, so I
had to change. It took a while to adjust, but now I HATE_THESE_CAPITALS
and Find_This_Style much more natural. The final result is that you
have a team that very much agrees on these style issues, and that
works together as a team. In my experience, as in sports, this team
spirit is a key factor in maintaining a high level of motivation.

Perhaps it is possible to operate a large complex project successfully
with Peter's view, but I have never seen it succeed. On the other hand,
I have seen the team view point work well, both in GNAT and other
projects I have worked on, though I have never seen a project where
the consistency of style achieved for GNAT was as pronounced.

Robert Dewar

Re: Language Choice and Coding style

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>Peter Herman says

>  "I like it to allow everyone to show his personal style.
>  This is even important because the motivation is very much higher.
>  They are and should keep to be individuals.
>  And I like it when I see at first glance "Oh that is the typical
>  style of Barbara". This holds for code production inside bodies."

>Fascinating to see this point of view expressed so directly (it is I am
>sure shared in practice by many programmers).

>To me this "ego-centered" style of programming is deadly. It promotes a
>situation where in a big project code is owned by individuals. Clearly
>if you see that some code is "typical Barbara" style, then the next step
>is that only Barbara touches that code, and a consequence is that only
>Barbara really looks at that code.

>This is not team work, this is a collection of individuals working together,
>and you lose the advantages of working as a team. In particular:

>   a) If Barbara starts polishing her resume, you can be in big trouble
>   b) Only one pair of eyes looks at Barbara's code (other people don't
>        because they have their own style they prefer to read).

That's more of a management problem. It's whoever is in charge's
responsibility to make sure this kind of thing doesn't happen, and
formatting editors canhelp to make sure that no one cangive the excuse
that someone else's code is difficult for them to read.



Best Regards
John McCabe <john@assen.demon.co.uk>

software engineering and the notion of authorship

[Fergus Henderson]

In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

>To me this "ego-centered" style of programming is deadly.  It promotes a
>situation where in a big project code is owned by individuals.

I agree consistency is very important, as is maintainability.
It is essential to make sure that the overall design is consistent.
It is also essential that every part of the system is sufficiently
clear, well-documented, and so forth that any programmer could make
modifications to that part of the system, or take over responsibility
for that part of the system, and consistency of style is important
in facilitating this.  But I'm not convinced that recording
authorship or assigning areas of responsibility is a bad idea.

>you lose the advantages of working as a team.

Teamwork has it's own disadvantages.  In particular, productivity goes
way down!  (See "The Mythical Man-Month".)  If there is a problem
in a particular piece of code, it makes sense for the expert on
that subsystem to be the one to fix it.  They'll be able to do
it quicker, and with less likelyhood of error, than someone who
is not an expert on that subsystem.  It also makes sense for the
expert on a subsystem to be part of the code review team for any
changes to that subsystem, and assigning some degree of responsibility
to the expert can increase their motivation to do a good job of
code review.  Of course you need to make sure that the code is
sufficiently consistent, well-documented, etc. that anyone can _become_
the expert, when and if necessary.  But it's impossible for everyone
to be the expert on everything.

>in the GNAT project ...  You absolutely cannot tell
>who wrote code from its style, and indeed we strongly discourage the notion
>of authorship (we never for example attach names to units). Sure in practice
>certain people know certain code well and our informally the experts in
>particular areas, but if you look at the revision histories, you will see
>that all sorts of people work in all parts of the system.

What's wrong with recognizing the role of these informal experts?

>In my experience, as in sports, this team
>spirit is a key factor in maintaining a high level of motivation.

As in sports, I think it is useful to assign individuals particulars
areas of responsibility.  In Australian rules football, a team has
forwards, a backline, centers, and on-ball players (rovers, a ruckman
or two, and so forth).  It's not just a mob.

And while team spirit is important, so is individual motivation, and
a little bit of competition between players is a good thing, so long
as they're competing for success in meeting the team's objectives,
not competing for the ball.  A team plays better if they have a good
reserves team, with players competing for spots in the team.  And
players within a team compete for the team's best-and-fairest awards.

The important thing, IMHO, is finding the right balance.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Peter Hermann]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

: >To me this "ego-centered" style of programming is deadly.  It promotes a
: >situation where in a big project code is owned by individuals.

: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this.  But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.

Thank you for your contribution (you are saving my time  ;-).

Special topic "authorship": this has revealed to be one of the
most important properties of our systems. Each routine has
short "date/author/topic"-comments of creation and all subsequent updates.

[snip]
: And while team spirit is important, so is individual motivation, and
[snip]
: The important thing, IMHO, is finding the right balance.

agree

I also agree to most of the rules given in "Ada Quality and Style"
and it is a fun to read this document because it is 
spreading a feeling of deep SE-experience of its authors.
OTOH, "honny soit qui mal y pense", I think it is a bad idea
to impose EXTRA rules on human beings which do not have an important
justification.

E.g. it is of utmost importance to request variable names
which bear its exact meaning, it is not at all important 
to force a programer to_type_in_any_capital_letters
when he chooses to be lazy like me ;-)

That's why Ada is so great with its minimum
consens of absolute necessities at the man-machine-interface.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: software engineering and the notion of authorship

[Jakob Engblom]

Fergus Henderson wrote:
> 
> In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
> 
> >To me this "ego-centered" style of programming is deadly.  It promotes a
> >situation where in a big project code is owned by individuals.

Ego-less programming is absolutely necessary to produce large functioning
software. Or at least to maintain it later.

> 					 If there is a problem
> in a particular piece of code, it makes sense for the expert on
> that subsystem to be the one to fix it.  They'll be able to do
> it quicker, and with less likelyhood of error, than someone who
> is not an expert on that subsystem.  

Yeah, but the real problem comes 10 years down the road, when the experts
have quit or died or moved to other projects and plain do not remember the
wonderfully complicated code they created back in '96... 

Using a "just complicated enough to do the job", "ego-less" programming style,
makes it much easier for the new maintenance developer working with the
program in 2006... the savings in the long run far outweigh the lack of
"personal style" in the code. 

> >in the GNAT project ...  You absolutely cannot tell
> >who wrote code from its style, and indeed we strongly discourage the notion
> >of authorship (we never for example attach names to units). Sure in practice
> >certain people know certain code well and our informally the experts in
> >particular areas, but if you look at the revision histories, you will see
> >that all sorts of people work in all parts of the system.

!!!! SUPEr!!!!!

Only in software do we even think of accepting personal style like... it would
be quite devastating in any other industry if an engineer insisted on using 
left-handed instead of right-handed bolts "because I feel creative today"..
things have to fit together, and TEAM WORK is the essential part of any
programming project.

/jakob

-- 
----------------------------------------------------------------------------
 Jakob Engblom. Computer Science Student @ Uppsala University, Sweden 
                 presently an ERASMUS exchange student in Stuttgart, Germany
 email Uppsala: jakob@docs.uu.se       
 email Stuttgart: engblojb@tick.informatik.uni-stuttgart.de
 homepage: http://www.csd.uu.se/~jakob

Re: software engineering and the notion of authorship

[Fergus Henderson]

Jakob Engblom <engblojb@tick.infomatik.uni-stuttgart.de> writes:

>Ego-less programming is absolutely necessary to produce large functioning
>software. Or at least to maintain it later.

That's a slogan.  If you have some justification for it, please state it.

>> 					 If there is a problem
>> in a particular piece of code, it makes sense for the expert on
>> that subsystem to be the one to fix it.  They'll be able to do
>> it quicker, and with less likelyhood of error, than someone who
>> is not an expert on that subsystem.  
>
>Yeah, but the real problem comes 10 years down the road, when the experts
>have quit or died or moved to other projects and plain do not remember the
>wonderfully complicated code they created back in '96... 

If the code is clear, well-written and well-documented -- you should
use code reviews to ensure this -- then I don't see why attaching
authorship labels or assigning clear areas of responsibility is going
to cause you problems 10 years down the road.

>Using a "just complicated enough to do the job", "ego-less" programming style,
>makes it much easier for the new maintenance developer working with the
>program in 2006... the savings in the long run far outweigh the lack of
>"personal style" in the code. 

Of course you should not make the code more complicated than is necessary. 
No self-respecting computer scientist or software engineer would
suggest otherwise.  I'm not arguing for personal style -- I agree that
consistency makes maintenance easier.  What I am arguing for is some
degree of personal responsibility.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Richard A. O'Keefe]

fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>>Yeah, but the real problem comes 10 years down the road, when the experts
>>have quit or died or moved to other projects and plain do not remember the
>>wonderfully complicated code they created back in '96... 

>If the code is clear, well-written and well-documented -- you should
>use code reviews to ensure this -- then I don't see why attaching
>authorship labels or assigning clear areas of responsibility is going
>to cause you problems 10 years down the road.


Fergus and I see eye-to-eye on many points.
However, he is working in a project with a small number of brilliant
programmers who are good at writing comments.

I had to maintain a large chunk of code which had only one comment (well,
I tell a lie, there were two: a commented out chunk of code -- with no
reason -- and the copyright notice) and a lot of one or two letter 
identifiers.  And code reviews were not a political practicality with
that piece of code:  it had been written by the _founder_ of the
company before I joined.  And he had left.

The "ego-less culture" that allows programmers to adopt a common style
is the same culture that is needed to allow the founder to submit his
precious work to other people's judgement.  I'm not arguing against
personal responsibility, only that the responsibility is responsibility
to *communicate*, and that adopting a common style in a project is one
of the things that *makes* the code clear.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: software engineering and the notion of authorship

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>Fergus and I see eye-to-eye on many points.
>However, he is working in a project with a small number of brilliant
>programmers who are good at writing comments.

Well, after that comment, our project is certainly going to have
trouble keeping the egos under control ;-) ;-) ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Paul Eggert]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> I had to maintain a large chunk of code which had only one comment ...
> and a lot of one or two letter identifiers.  And code reviews were not
> a political practicality with that piece of code:
> it had been written by the _founder_ of the company before I joined.
> And he had left.

I had to maintain a similar batch of code, and if I'm not mistaken it
was written by the same guy for his previous company.  It was a joy.
That guy really knew what he was doing, and his code taught me a lot of things.

But I had to write documentation describing the program so that
everybody else at our company could follow what was going on.
The documentation was considerably longer than the program that it described.

In extreme cases like this, the usual software engineering management
principles often don't work well.  And extreme cases are often the
most profitable ones....

Re: software engineering and the notion of authorship

[John Byerly]

Jakob Engblom wrote:
>
> Yeah, but the real problem comes 10 years down the road, when the experts
> have quit or died or moved to other projects and plain do not remember the
> wonderfully complicated code they created back in '96...

That's why we document code.  Software engineering is the only engineering
discipline that considers documentation to be optional.  And even when documents
are produced, they are almost never updated after the code is written.

Speaking as someone who always seems to get stuck maintaining code, I find that
something as simple as comments go a long way toward making my job easier.

> Using a "just complicated enough to do the job", "ego-less" programming style,
> makes it much easier for the new maintenance developer working with the
> program in 2006... the savings in the long run far outweigh the lack of
> "personal style" in the code.

I disagree.  I started my software engineering career maintaining undocumented
FORTRAN code that was about as ego-less as you get and the thing was a nightmare.
More recently, I have maintained well commented, C++ code that was created using
a style that was unfamiliar.  This experience was much less painful.

> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using
> left-handed instead of right-handed bolts "because I feel creative today"..

That is why this is called _soft_ware.  To a certain extent, we have more
flexibility in creating our product than, say, a mechanical engineer.  In a
strict sense, however, our deliverables are object files, libraries, executables,
etc., which had better match the specifications.  This is the "right-handed bolt".

> things have to fit together, . . .

Quite true.  That is what an Interface Specification is for.


__________________________________________________________________________
John A. Byerly                            Which way to Flower Mound, TX?
The Dalmatian Group, Inc.
User Interface Specialists                Currently on site at:
jbyerly@dalmatian.com                       Motorola -- Chandler, AZ

Re: software engineering and the notion of authorship

[The Amorphous Mass]

On Mon, 8 Jul 1996, Jakob Engblom wrote:

> !!!! SUPEr!!!!!
> 
> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using 
> left-handed instead of right-handed bolts "because I feel creative today"..
> things have to fit together, and TEAM WORK is the essential part of any
> programming project.

  I have a simple question:  Do we all mean the same thing by 
"programming style?"  It seems that the people supporting individual 
style are assuming that there are *some* coding standards being followed, 
and the "style" boils down to formatting idioms and whether they prefer 
for, while, do-while, etc, or the _exact_ way they name variables (for 
example, if the convention is To_Write_Variables_This_Way then one 
person's List_Of_Items will be another person's Item_List, etc).  The people 
dissing it seem to think that it implies that no standard, or no 
significant standard is being followed.  Using a left-handed bolt one 
day "because I feel creative" is like writing a module in SNOBOL one day 
"because I feel creative."  It doesn't have anything to do with the 
particular coding idiom that a programmer uses (which should be 
_consistent_:  it is a means of expression, not a whim), and it doesn't mean 
that the idioms can't be standardized to a certain extent, and it certainly 
doesn't mean that one person cannot read another person's code.  I 
learned C from a textbook whose formatting style I immediately disliked, 
but which I was nevertheless quite able to read.  Now I can see both Mr. 
Dewar's and Mr. Henderson's side of this issue -- I'm just getting the 
feeling that not everyone is talking about the same thing.
  If comments and documentation are counted as part of the code I would 
be amazed to hear that there is a single project of any significant size 
where it is impossible to tell who wrote the code, considering that 
writing styles tend to be individual.  Especially if the comments go into 
any depth. :-)

James Robinson.........................................james-robinson@uiowa.edu
   "To be prepared against surprise is to be /trained/.  To be prepared for
   surprise is to be /educated/."  --James Carse, _Finite_and_Infinite_Games_

Re: software engineering and the notion of authorship

[Robert Dewar]

James Robinson says

"  If comments and documentation are counted as part of the code I would
be amazed to hear that there is a single project of any significant size
where it is impossible to tell who wrote the code, considering that
writing styles tend to be individual.  Especially if the comments go into
any depth. :-)
"

Try looking at the GNAT souces, you may be amazed :-)

Re: software engineering and the notion of authorship

[Ralph Silverman]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:

: >To me this "ego-centered" style of programming is deadly.  It promotes a
: >situation where in a big project code is owned by individuals.

: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this.  But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.

: >you lose the advantages of working as a team.

: Teamwork has it's own disadvantages.  In particular, productivity goes
: way down!  (See "The Mythical Man-Month".)  If there is a problem
: in a particular piece of code, it makes sense for the expert on
: that subsystem to be the one to fix it.  They'll be able to do
: it quicker, and with less likelyhood of error, than someone who
: is not an expert on that subsystem.  It also makes sense for the
: expert on a subsystem to be part of the code review team for any
: changes to that subsystem, and assigning some degree of responsibility
: to the expert can increase their motivation to do a good job of
: code review.  Of course you need to make sure that the code is
: sufficiently consistent, well-documented, etc. that anyone can _become_
: the expert, when and if necessary.  But it's impossible for everyone
: to be the expert on everything.

: >in the GNAT project ...  You absolutely cannot tell
: >who wrote code from its style, and indeed we strongly discourage the notion
: >of authorship (we never for example attach names to units). Sure in practice
: >certain people know certain code well and our informally the experts in
: >particular areas, but if you look at the revision histories, you will see
: >that all sorts of people work in all parts of the system.

: What's wrong with recognizing the role of these informal experts?

: >In my experience, as in sports, this team
: >spirit is a key factor in maintaining a high level of motivation.

: As in sports, I think it is useful to assign individuals particulars
: areas of responsibility.  In Australian rules football, a team has
: forwards, a backline, centers, and on-ball players (rovers, a ruckman
: or two, and so forth).  It's not just a mob.

: And while team spirit is important, so is individual motivation, and
: a little bit of competition between players is a good thing, so long
: as they're competing for success in meeting the team's objectives,
: not competing for the ball.  A team plays better if they have a good
: reserves team, with players competing for spots in the team.  And
: players within a team compete for the team's best-and-fairest awards.

: The important thing, IMHO, is finding the right balance.

: --
: Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
: PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
************begin r.s. response*************

	a closely related question is:
	if persons who are supposed to be
		programmers
	can usefully work in groups
	or teams
		were such persons not able
		to program individually...
	?

	generally,  one may suppose,
	those capable of programming
	individually would be accepting of
		individuality
	.

************end r.s. response***************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: software engineering and the notion of authorship

[Fergus Henderson]

I got a useful reply from Scott Ellsworth <fuz@deltanet.com> via email;
he said he wouldn't mind if I posted it.

> Assuming the original poster is not a doof, what I assume he means by 
> ego-less programming is simply programming for clarity, not cleverness.  
> Often, if someone's name is atattched to a product, they get possessive, 
> and try to do things in the most complex and clever way they know how.  
> This does not actually give them a better rep in most other people's 
> eyes, but inexperienced programmers often think it should.
> 
> Proper training can break someone of this, just like it can break them of 
> not commenting code that needs it, and proper code reviews can make 
> overly clever code be rewritten for clarity.  Of course, if the code is 
> time critical and needs to be faster, then clever is good.
> 
> Personally, I approve of pride of creation in most software projects, as 
> long as that includes the stated assumption that your creation will 
> become someone elses creation once you move to another project.

That reply explains to me some of the motivations behind ego-less programming
better than many of the other articles in this thread.

For the moment, I remain open-minded about whether or not recording authorship
is advantageous or disadvantageous overall.  One thing is certain, and that
is that knowing the dangers helps one to avoid them.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: software engineering and the notion of authorship

[Robert Dewar]

Ralph Silverman asks

        a closely related question is:
        if persons who are supposed to be
                programmers
        can usefully work in groups
        or teams
                were such persons not able
                to program individually...
        ?

        generally,  one may suppose,
        those capable of programming
        individually would be accepting of
                individuality

I have worked completely on my own (e.g. several complete operating systems
written for Honeywell and the first version of Macro-SPITBOL), in small
teams (SPITBOL 370 was a 2-person effort, Realia COBOL was a 3-peson
effort), and in larger groups (GNAT is a several person effort).

I see no real differences. In each case, an absolute standard of consistency
is essential throughout the program. Remember that one of the major needs
for consistency is for maintenance, and how many people developed a project
is rather irrelevant when considering maintenance needs (all the programs
I mention abvove have been maintained by multiple people over the years).

When you are working alone, you can of course set your own standards of
consistency, but in fact I see many 1-person programs that are a mightmare
(oops typo, but rather nice one, I will leave it in :-)          nightmare
of inconsistency. I couldn't possibly work that way myself.

When you are working together, you have first to agree on the standards
of consistency that you will use. That means you don't get to choose yourself
every detail, so what? For example, in the GNAT project, as I have mentioned
before, I was forced to change from ALL_UPPER_CASE_IDENTIFIERS to the more
usual Mixed_Case_Identifiers since that is what the team preferred. It was
awkward at first (you always find it easier to do what you are used to, and
to read code in the style you are used to), but it would never have occurred
to me to react to that awkwardness by insisting on continuing to SHOUT when
I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
style (now it would be hard to go back).

However, I see many programmers for whom not only does it occur to them to
react in this situation by insisting on using their own style, but they do it
and their management permits it. I am certainly capable of programming
individually, but I am definitely NOT willing to accept this particular
brand of individuality, not for a moment!

The team effort issue of course only applies to groups, but there is another
factor that I think is important. Whether you are working alone or in a
group, an elegantly structured and consistently presented source code is
a source of pride, and that is definitely a positive dynamic in any project.

Re: software engineering and the notion of authorship

[Mike Curtis]

Robert Dewar wrote:

------ <snip> -------
> .... but it would never have occurred
> to me to react to that awkwardness by insisting on continuing to SHOUT when
> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
> style (now it would be hard to go back).
> 

Ah Robert, but if you were insisting on writing the code in Ada and everyone else 
wanted to use C would you fall in with them so readily.

Mike

-- 
Mike Curtis               tel: +44 1753 679935
curmi02@unix9.ingres.com  fax: +44 1734 442453
Computer Associates International

Re: Language Choice and Coding style

[Dan Evens]

Robert Dewar wrote:
> 
> Samuel says
> 
> "Anyway, for this particular small area -- code formatting -- the best
> approach is to use a formatting editor, so everybody can set up his
> *own* preferences and see the code the way *he* finds most readable.
> (Or she.)"
> 
> I strongly disagree. In theory this sounds OK, but style covers much more
> than simple rules that can be messed around with by a formatting editor.
> If a team is not willing to agree on unimportant little things, but insists
> on going their own individual way, I think you have little hope of
> achieving a high degree of coding style consistency, something I think
> is vital for the success of software projects with more than one person
> involved.

I strongly agree with Robert here.  Coding style is a very long book,
and formatting is one chapter. And not a particularly long chapter.
Things like naming conventions, loop initializations, number of lines
in code blocks, number of args to routines, etc., are all important
to coding style also. For projects with hundreds of subroutines and
many tens of thousands of lines of code, some of these things can make
just HUGE differences to things like the app being maintainable.

-- 
The preceding are my opinions alone and have nothing
whatever to do with my employer.  I don't even know what my
employer thinks. I'm not even real sure who the CEO is.
Dan Evens

Re: Language Choice and Coding style

[John McCabe]

smize@Starbase.NeoSoft.COM (Samuel Mize) wrote:

<..snip..>

>Anyway, for this particular small area -- code formatting -- the best
>approach is to use a formatting editor, so everybody can set up his
>*own* preferences and see the code the way *he* finds most readable.
>(Or she.)

I'm not sure how this solves the problem. If each user sets up the
formatting editor the way they like, then you're still going to get
lots of different formats. On the other hand, if one person sets up
the formatting editor (e.g. using ada-mode on emacs) then no one has
to worry about how it looks as the editor will have taken care of it.



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Samuel Mize]

In article <836339497.14712.2@assen.demon.co.uk>,
John McCabe <john@assen.demon.co.uk> wrote:
>smize@Starbase.NeoSoft.COM (Samuel Mize) wrote:
>
><..snip..>
>
>>Anyway, for this particular small area -- code formatting -- the best
>>approach is to use a formatting editor, so everybody can set up his
>>*own* preferences and see the code the way *he* finds most readable.
>>(Or she.)
>
>I'm not sure how this solves the problem. If each user sets up the
>formatting editor the way they like, then you're still going to get
>lots of different formats. On the other hand, if one person sets up
>the formatting editor (e.g. using ada-mode on emacs) then no one has
>to worry about how it looks as the editor will have taken care of it.

True, given the current state-of-the-practice for editors.  I believe
that editors exist that format the code as they read it in, to fit
your preferences.  The next guy gets the code auto-formatted to HIS
preferences (if using that editor).  (Or her.)  Everyone sees the code
the way they like it, and how it's stored on disk is irrelevant
(the compiler won't care).

However, I haven't seen stand-alone editors like this available
commercially, I've just seen mention of them in research articles.
The Rational editor I'm using at work gives us some of this ability,
but it's part of an expensive environment.

I'm hoping someone will post a message starting "Oh, you're talking
about editors like ..."

>Best Regards
>John McCabe <john@assen.demon.co.uk>

Samuel Mize

Re: Language Choice and Coding style

[Jeff Dege]

On 2 Jul 1996 21:18:35 -0500, Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
: True, given the current state-of-the-practice for editors.  I believe
: that editors exist that format the code as they read it in, to fit
: your preferences.  The next guy gets the code auto-formatted to HIS
: preferences (if using that editor).  (Or her.)  Everyone sees the code
: the way they like it, and how it's stored on disk is irrelevant
: (the compiler won't care).

Your CM system's difference utility will.  Quite often the fastest
way to find where a newly introduced bug is hiding is to run some
sort of diff across the revision that introduced it.  I'd hesitate
to lose that ability in exchange for the minimal benefit of allowing
programmers to waste their time futzing around with braces.

Of course, you may see context-aware diff utilities for the language
you develop in, assuming you only develop in one, and if you're
lucky it may even work with the current version of the language.
And if you have a reformatting system that is guaranteed not to mess
up your code, nope, not even once, you'll have a system that is in
no way better than what you had before.

-- 
  Friendship is born at that moment when one person says to another:
  "What!  You, too?  Thought I was the only one."
                                             -C.S. Lewis

Re: Language Choice and Coding style

[Robert Dewar]

Jeff said

"Your CM system's difference utility will.  Quite often the fastest
way to find where a newly introduced bug is hiding is to run some
sort of diff across the revision that introduced it.  I'd hesitate
to lose that ability in exchange for the minimal benefit of allowing
programmers to waste their time futzing around with braces."

(talking about the use of formatting editors to allow programmers to follow
their own tastes in formatting).

Yes, indeed. And why in any case do we consider the use of formatting
editors -- just to allow programmers to follow their own idiosyncratic
tastes in formatting?

But (a) this is of no value, there is no point in indulging idiosyncrasy
unless there is some definite technical advantage in doing so, and none
can be claimed for simple formatting issues.

More importantly, (b) if programmers can't even agree to use a common
standard for trivial formatting issues, you have on your hands the kind
of personality that just does not like conformity and consistency. We
have certainly seen that personality displayed by a few people here. If
you have someone like that, then, much more seriously than not indenting
right, they are likely to fight against conformity to much more important
requirements for consistent standards at the design level.

People who insist on coding in their own style should stick to one person
projects in my opinion. Consistency and conformity at *all* levels of
a program, ranging from the simplest formatting issues to fundamental
design structure, is an absolute requirement in multi-person projects.

Re: Language Choice and Coding style

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>Yes, indeed. And why in any case do we consider the use of formatting
>editors -- just to allow programmers to follow their own idiosyncratic
>tastes in formatting?

>But (a) this is of no value, there is no point in indulging idiosyncrasy
>unless there is some definite technical advantage in doing so, and none
>can be claimed for simple formatting issues.

>More importantly, (b) if programmers can't even agree to use a common
>standard for trivial formatting issues, you have on your hands the kind
>of personality that just does not like conformity and consistency. We
>have certainly seen that personality displayed by a few people here. If
>you have someone like that, then, much more seriously than not indenting
>right, they are likely to fight against conformity to much more important
>requirements for consistent standards at the design level.

This is entirely the point (well my point anyway) - formatting in the
terms of overall design is trivial and can be easily modified by
machine, however as has been pointed out, it is common for two people
to find each other's method of formatting very difficult to read.
Who's method is correct? Neither! So why should there be a problem
allowing the use of formatting editors which will present the code to
you in a format that you find highly readable, and easier to
understand and modify?

As far as conformity is concerned, where would we be now if everyone
in the 15th and 16th century had conformed to the opinion that the
world was flat! You would certainly not be where you are now!
Conformity restricts imagination and individuality.

>People who insist on coding in their own style should stick to one person
>projects in my opinion. Consistency and conformity at *all* levels of
>a program, ranging from the simplest formatting issues to fundamental
>design structure, is an absolute requirement in multi-person projects.

Just as an example, the current project I am working on has a set of
"coding rules" defined by our German customer. Early on in the project
I sat with my team and we discussed these rules. In many cases we
could see no technical justification for the rules, and indeed some of
them were just stupid and to those rules we stated that we would
attempt to stick to them, but would not guarantee it. We did however
agree on what way we would do things instead of what had been defined
by the customer and it worked successfully.

The formatting rules, however, we practically ignored as we knew that
with very little effort (using emacs ada-mode) we could comply with
those rules practically without even thinking about them.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Phil Howard]

On 3 Jul 1996 08:27:05 -0400 Robert Dewar (dewar@cs.nyu.edu) wrote:

| More importantly, (b) if programmers can't even agree to use a common
| standard for trivial formatting issues, you have on your hands the kind
| of personality that just does not like conformity and consistency. We
| have certainly seen that personality displayed by a few people here. If
| you have someone like that, then, much more seriously than not indenting
| right, they are likely to fight against conformity to much more important
| requirements for consistent standards at the design level.
|
| People who insist on coding in their own style should stick to one person
| projects in my opinion. Consistency and conformity at *all* levels of
| a program, ranging from the simplest formatting issues to fundamental
| design structure, is an absolute requirement in multi-person projects.

Certainly programmers don't agree on what the common standard _should_ be.
We see that here if we dare describe our preferences.

I have found that certain styles are very hard to read and other styles
are very easy.  You can bet I avoid the styles that are hard to read.
Following up on what you said, I'd suggest a programmer who finds the
standard style where they work to be hard to read to polish their resume.

But I've also found programmers who find my style hard to read, and who
use a style I find hard to read.  It's not just a matter of degree; it can
be totally opposite.

I'd be curious, however, if the diversity of styles among programmers is
generally reflected in similar proportion in the diversity of style in
different programming environments with a chosen style.

BTW, just how many different styles are there?
--
Phil Howard KA9WGN             +---------------------------------------------+
Unix/Internet/System Admin     |  When freedom is outlawed....               |
CLR/Fast-Tax                   |          ....only outlaws will be free!     |
phil@clr.com,phoward@clr.com   +---------------------------------------------+

Re: Language Choice and Coding style

[Peter Hermann]

Phil Howard (phoward@sunsrv13.clr.com) wrote:
: Certainly programmers don't agree on what the common standard _should_ be.
: We see that here if we dare describe our preferences.

This is exactly the crucial point.

: I have found that certain styles are very hard to read and other styles
: are very easy.  You can bet I avoid the styles that are hard to read.
: Following up on what you said, I'd suggest a programmer who finds the
: standard style where they work to be hard to read to polish their resume.

: But I've also found programmers who find my style hard to read, and who
: use a style I find hard to read.  It's not just a matter of degree; it can
: be totally opposite.

I fully agree with you.

We take the indendation, as an example, which can be easily enforced
by machine:
With growing experience, a softworker will tend to accept indentation
and use it on his own because long-term experience indicates 
that this is indeed very practical.
Look at this piece of code

	    for i in field'range loop
	       field(i) := value;
	    end loop;

Why should I seriously hinder a programer
(by means of some stupid preprocessor) to choose a
possibly clearer sequence of statements like

	    for      i in field'range loop
	       field(i) := value;
	    end loop;

As I said before, I actively hate imposing extra rules to the
human programmer. This can be left to the C/C++-hackers
which dearly need extra rules to survive.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Language Choice and Coding style

[John McCabe]

smize@Starbase.NeoSoft.COM (Samuel Mize) wrote:

<..snip..>

>True, given the current state-of-the-practice for editors.  I believe
>that editors exist that format the code as they read it in, to fit
>your preferences.  The next guy gets the code auto-formatted to HIS
>preferences (if using that editor).  (Or her.)  Everyone sees the code
>the way they like it, and how it's stored on disk is irrelevant
>(the compiler won't care).

I see what you mean. Presumably (in response to Jeff Dege's posting)
you could also configure the editor to save the information in a
pre-defined format to ensure you don't get the type of problem he
mentioned with your CM diff utility.

>However, I haven't seen stand-alone editors like this available
>commercially, I've just seen mention of them in research articles.
>The Rational editor I'm using at work gives us some of this ability,
>but it's part of an expensive environment.

>I'm hoping someone will post a message starting "Oh, you're talking
>about editors like ..."

In actual fact, to a certain extent you could do that with emacs'
ada-mode by setting up the ada-mode-hook to run a formatting routine,
and the exit-ada-mode-hook (or whatever it's called) to run a
different one.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[John McCabe]

ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) wrote:

<..snip..>

>for one thing i have an extreme antipathy:
>the enforcement of rules which do not have a useful justification.
>if someone chooses for himself to carve all in CAPS, he may
>freely do so, but he should not bother me to request this from me.

I agree entirely as you probably noticed from my earlier posting.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Robert Dewar]

Peter Herman says

"for one thing i have an extreme antipathy:
the enforcement of rules which do not have a useful justification.
if someone chooses for himself to carve all in CAPS, he may
freely do so, but he should not bother me to request this from me."

However, a useful justification for rules is consistency, sometimes we
have to make an arbitrary decision whose ONLY justification is
consistency, and anyone who finds that unacceptable will not be
welcome in a team where consistency is considered critically important.

Re: Language Choice and Coding style

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>Peter Herman says

>"for one thing i have an extreme antipathy:
>the enforcement of rules which do not have a useful justification.
>if someone chooses for himself to carve all in CAPS, he may
>freely do so, but he should not bother me to request this from me."

>However, a useful justification for rules is consistency, sometimes we
>have to make an arbitrary decision whose ONLY justification is
>consistency, and anyone who finds that unacceptable will not be
>welcome in a team where consistency is considered critically important.

Interesting point - for a sample of consistency (or rather not), check
out the TLD Mil-Std-1750A RTS code.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Laurent Guerby]

Robert> [...]
Robert> Sure in practice certain people know certain code well and our
Robert> informally the experts in particular areas, but if you look at the
Robert> revision histories, you will see that all sorts of people work in all
        ^^^^^^^^^^^^^^^^^^
Robert> parts of the system.

   Hum, I don't think GNAT sources are released will full revision
histories.  This can be a nice thing to do so, but I think the package
will be around 70 megs ;-).

   More on the topic, style consistency is a good thing, but from my
point of view the key point is keeping the documentation level high
(quantity and quality ;-). The casing and code layout consistency is
nice but not as essential as consistent documentation.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: software engineering and the notion of authorship

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would all respondents *please* take that into account. Followups set.]

Mike Curtis <curmi02@unix9.ingres.com> wrote:
>Robert Dewar wrote:
>------ <snip> -------
>> .... but it would never have occurred
>> to me to react to that awkwardness by insisting on continuing to SHOUT when
>> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
>> style (now it would be hard to go back).
>> 
>
>Ah Robert, but if you were insisting on writing the code in Ada and everyone else 
>wanted to use C would you fall in with them so readily.
>
>Mike

Re: Language Choice and Coding style

[mfinney]

In <Pine.A32.3.91.960621114420.61918K-100000@green.weeg.uiowa.edu>, The Amorphous Mass <robinson@blue.weeg.uiowa.edu> writes:
>  Except for the "Hungarian notation" silliness, the idea of 
>spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal 
>idiom

I don't think that is true.  I saw that style become used as soon as
line printers had lower case symbols available consistently on the
print train.  I don't think that either Smalltalk or PASCAL were
available (at least not widely) then.

It is fundamentally an issue of writing and detecting word breaks
and what reads easiest.  I suspect that using _ to separate words
doesn't work well because in many cases it is hard to read -- especially
when printing with very little leading between lines.  I tried both
styles (once I had lower case characters available) and simply found
that the squashedTogetherStyle reads better.  Not to mention that
the use of the shift key is easier for a touch typist than constantly
hitting the _ key.

Re: Language Choice and Coding style

[Robert Dewar]

"It is fundamentally an issue of writing and detecting word breaks
and what reads easiest.  I suspect that using _ to separate words
doesn't work well because in many cases it is hard to read -- especially
when printing with very little leading between lines.  I tried both
styles (once I had lower case characters available) and simply found
that the squashedTogetherStyle reads better.  Not to mention that
the use of the shift key is easier for a touch typist than constantly
hitting the _ key."

First, the underline used as a break character should be printed ON the
base line, NOT in the underline position, many fonts are defective in
this respect.

Second, I think convenience of the typist is monumentally unimportant,
and not a criterion that should be used in discussions of how code should
be layed out. 

Re: Language Choice and Coding style

[mfinney]

In <dewar.835574607@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:

>First, the underline used as a break character should be printed ON the
>base line, NOT in the underline position, many fonts are defective in
>this respect.

Even when they are not, if the leading between lines is insufficient
then the underscore is hard to read.  Nevertheless, we generally have
to work with existing fonts and it is a common problem.  Even on 
screen.

>Second, I think convenience of the typist is monumentally unimportant,
>and not a criterion that should be used in discussions of how code should
>be layed out. 

The convenience of the typist is not important as to SHOULD, but is
extremely relevant to IN PRACTICE and is therefore relevant as an
explanatory mechanism for the adoption of squashedText over
non_squashed_text.

And regardless of both of the above points, the squashedText
still seems to read substantially better than the non_squashed_text
so, in my opinion, the squashedText sytle is preferable.  And I
have used both -- actually, I used the non_squashed_text first
and changed over because it was more readable in my opinion
(NOT because it was more typable).

Re: Language Choice and Coding style

[Louis Tribble]

Nasser Abbasi wrote:
> I'd like to know why do C and C++ programmer
> 
> pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada 
> programmers
> 
> Write_In_Clear_And_Nice_Way_Like_This ??

Two thoughts, for what they're worth:

(1) Typing skills may be a factor for some people. I don't touch type 
the top row as reliably as the other rows, so underscores slow me down 
(nevertheless, I _do_ use them).

(2) In languages like C, naming conventions are often used to simulate 
multiple visible name spaces (excuse the C, but the example fails in 
Ada):

    typedef struct Sequence_type Sequence;
    extern void sequence_create (...
    extern void sequence_insert (...
    extern void sequence_remove (...

Since there is no scope separator like the . in Ada or the :: in C++, 
the underscore gets pressed into service. If it is also used as the 
word separator, an informal ambiguity is introduced:

    typedef struct Sequence_Partial_type Sequence_Partial;
    extern void sequence_partial_create (...
    extern void sequence_partial_insert (...
    extern void sequence_partial_remove (...
    .
    .
    Sequence_Partial* dependents;
    .
    .
    while (sequence_partial_length (dependents)) {
        node = sequence_partial_remove (dependents);
        node_destroy (node);
    }

Avoiding the underscore as a word separator can help a (human) reader 
automatically discard the prefix and focus on the "meaningful" part of 
the name when the name appears in a context where the prefix is 
obvious:

    typedef struct SequencePartial_type SequencePartial;
    extern void sequencepartial_create (...
    extern void sequencepartial_insert (...
    extern void sequencepartial_remove (...
    .
    .
    SequencePartial* dependents;
    .
    .
    while (sequencepartial_length (dependents)) {
        node = sequencepartial_remove (dependents);
        node_destroy (node);
    }


Louis Tribble
letribble@msmail4.hac.com (until the mail scheme changes yet again...)

Re: Language Choice and Coding style

[Jerry van Dijk]

Nasser Abbasi (nasser@apldbio.com) wrote:

: Most  C and C++ programmers are more hippy , 1960's type, type of people,
: the anti-establishment crowd, who just want to be different,

Havn't been around a C shop at a bank lately, have we ?  :-))

: I remmember
: starting to first see ThisTypeOfWritingOfCode around 1985-1986 time
: frame

Actually, I think the ILikeALotOfCasing stuff is decending from Turbo Pascal 
4.0 which would more or less coincide with the '85 framework.

The one_true_style for_c_programmers has always been more_ada_like, but, as
C is case sensitive, without the casing.

The lpszUglyNotation is a MS thing, introduced by Windows (see the neverending 
thread on Hungarian notation :-)

The PascalNotation seems to have made a lot of headway into C++ territory 
although Stroustup et all at Bell Labs seem to be hanging on to the C
variety.

Which make me think of a boss I once had who insisted that all objects were
assigned coded names like 'E84jKS' and 'DFK-34_9' arguing that this way we
were forced to check everything very carefully... the same one that insisted
on using BASIC as it made sure the source was never lost...

Ahh, well, there I go again, showing my age again :-))


-- 
-----------------------------------------------------------------------
--  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
--  Banking Consultant   --              Member Team-Ada             -- 
--  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: Language Choice and Coding style

[Adam Beneschan]

jerry@jvdsys.nextjk.stuyts.nl (Jerry van Dijk) writes:
 >
 >Which make me think of a boss I once had who insisted that all objects were
 >assigned coded names like 'E84jKS' and 'DFK-34_9' arguing that this way we
 >were forced to check everything very carefully... the same one that insisted
 >on using BASIC as it made sure the source was never lost...
 >

Was this boss, by any chance, bald except for two triangular-shaped
tufts of dark hair sticking up from both sides of his head?

:)
                                -- Adam

Re: Language Choice and Coding style

[David Emery]

To quote from an unpublished part of the POSIX/Ada rationale:

   "POSIX/Ada identifiers are Long_and_Verbose, unlike POSIX/C 
    identifiers, which are trs."

            dave

Re: Language Choice and Coding style

[Darin Johnson]

> I'd like to know why do C and C++ programmer 
> 
> pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 
> 
> Write_In_Clear_And_Nice_Way_Like_This ??

In my experience, the ThisIsAVariable type of code is relatively
*new*.  None of the UNIX calls or types are named that way, but
Windows uses that style all over.  Thus I suspect that newer C
programmers programming on Windows tend to use that style.  (the style
was often used in SmallTalk as well, since "_" wasn't part of variable
names) In general, older people don't use case-specific stuff as much.
-- 
Darin Johnson
djohnson@ucsd.edu	O-
    "You used to be big."
    "I am big.  It's the pictures that got small."

Re: Language Choice and Coding style

[Nasser Abbasi]

>   From: softbase@mercury.interpath.com (Scott McMahan - Softbase Systems)


   : Tonight I'd like to ask a question I've always been afraid to ask.

   : I'd like to know why do C and C++ programmer 

   : pchWriteInThisStargeAndHardToReadWayLikeThis


>   You're obviously an idiot. 

hummm... I dont think I am an idiot. If I were, don't you think
I'll be the first to know it? after all, I know myself much
more than you do.

>  No real C programmer would use Hungarian notation, 
>  and certainly a real C programmer would never use an identifier 
>  longer than 6 bytes. No real C programmer would use more than one 
>  word in an identifier unless an underscore separated them.
>  The slimy things that use Hungarian notation, mixed case
>  identifiers, and descriptive identifiers hide from
>  real C programmers.

But REAL real C/C++ programmers can certinaly write identifiers longer than 
6 bytes. I guess you have not looked at any windows code lately or
looked at some of the popular C/C++ in the book stores. Almost all 
UseThisTypeOfWritingInTheCode this is one X window function I picked
by random as an example:

   XSetWindowBackgroundPixmap()

Are you saying the people who wrote windows and Xwindows stuff and 
and MFC and all the rest of it are not real C programmers?

   : My own personal analysis of the situation after long thought...

>   It's scary to contemplate, isn't it?

Not realy. I've always been like this. I like to think long :)

:   Scott

Nasser



-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)

Re: Language Choice and Coding style

[John McCabe]

nasser@apldbio.com (Nasser Abbasi) wrote:


>Tonight I'd like to ask a question I've always been afraid to ask.

<..snip..>

How about going back to Ada 83. Whose daft idea was it to copy the LRM
and start WRITING_STUFF_LIKE_THIS. I find pages and pages of
identifiers in upper case, interspersed with the odd lower case
keyword rather difficult to read. What I find most annoying though, is
being _told_ to write my code LIKE_THAT by bloody Germans!

But then again, why do some people think "gotten" is part of the
English language:-)

Glad I've got (or is it gotten) that off my chest.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Adam Beneschan]

john@assen.demon.co.uk (John McCabe) writes:
>
>But then again, why do some people think "gotten" is part of the
>English language:-)

My _Webster's Ninth New Collegiate_ dictionary lists both "got" and
"gotten" as acceptable past participles of "get." 

Of course, this dictionary is an American product, so it's possible
that the language of this dictionary is really some mutant language
bearing a vague resemblance to English . . .

                                -- Adam

Re: Language Choice and Coding style

[Peter Hermann]

for the record:


John McCabe (john@assen.demon.co.uk) wrote:
<..snip..>
: being _told_ to write my code LIKE_THAT by bloody Germans!


in comp.lang.ada


--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Language Choice and Coding style

[Alan Brain]

ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) wrote:
>
>for the record:
>
>John McCabe (john@assen.demon.co.uk) wrote:
><..snip..>
>: being _told_ to write my code LIKE_THAT by bloody Germans!
>
>in comp.lang.ada

Liebe Peter,

Es macht nichts. Nuer Inselaffensprache, InselAffenSprache oder INSEL_AFFEN_SPRACHE.

(Free Translation : Be kind to him, he's not bad for a Pommie Bastard) :-)

Re: Language Choice and Coding style

[John McCabe]

Alan Brain <aebrain@dynamite.com.au> wrote:

>ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) wrote:
>>
>>for the record:
>>
>>John McCabe (john@assen.demon.co.uk) wrote:
>><..snip..>
>>: being _told_ to write my code LIKE_THAT by bloody Germans!
>>
>>in comp.lang.ada

>Liebe Peter,

>Es macht nichts. Nuer Inselaffensprache, InselAffenSprache oder INSEL_AFFEN_SPRACHE.

>(Free Translation : Be kind to him, he's not bad for a Pommie Bastard) :-)

Didn't realise Scotsmen were considered pommies!





Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Language Choice and Coding style

[Nasser Abbasi]

   From: adam@irvine.com (Adam Beneschan)
   Newsgroups: comp.lang.ada
   Date: 24 Jun 1996 19:02:31 GMT

   john@assen.demon.co.uk (John McCabe) writes:
   >
   >But then again, why do some people think "gotten" is part of the
   >English language:-)

   My _Webster's Ninth New Collegiate_ dictionary lists both "got" and
   "gotten" as acceptable past participles of "get." 

   Of course, this dictionary is an American product, so it's possible
   that the language of this dictionary is really some mutant language
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   bearing a vague resemblance to English . . .
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Like fer sure ! The American English Langauge Ain't No Mutant of no 
langauge, dude ! 

Nasser

ps. Mutation is really nothing but a random act of nature, if the 
product of mutation is weak, the mutant subject will not survive nature, 
and the mutation will not by repreated by generational reproduction, and 
the random act will be as if not existed, else it will progress and 
spread among generations, and will become after millions of years the 
real thing.



-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 1.e4 !!)
I'am hooked on programming and can't get out ....

Re: Language Choice and Coding style

[Ian Ward]

In article 0@assen.demon.co.uk, john@assen.demon.co.uk (John McCabe) writes:

>How about going back to Ada 83. Whose daft idea was it to copy the LRM
>and start WRITING_STUFF_LIKE_THIS. I find pages and pages of
>identifiers in upper case, interspersed with the odd lower case
>keyword rather difficult to read.

I have to say that I find it ok, I guess it is down to what 
one is used to.

> What I find most annoying though, is
>being _told_ to write my code LIKE_THAT by bloody Germans!
>

If the staff at your company learn German, and French, well
enough, and funding allows, then perhaps your company can
become prime contractors in future projects.

Alternatively, you could consider a successful career in
tabloid journalism, I would not be too surprised if the 
Daily Mirror has a few openings;-)

Best regards,
Ian.

Re: Language Choice and Coding style

[Michael R. Hartwig]

In article <nh3f3pppsl.fsf@paralysys> nasser@apldbio.com (Nasser Abbasi)
  writes: 

> Tonight I'd like to ask a question I've always been afraid to ask.
> 
> I'd like to know why do C and C++ programmer 
> 
> pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 
> 
> Write_In_Clear_And_Nice_Way_Like_This ??

[snip]

> My own personal analysis of the situation after long thought is that 
> it is a cultural thing.  
> 
> Most  C and C++ programmers are more hippy , 1960's type, type of people,
> the anti-establishment crowd, who just want to be different, and so 
> they adjust the code more so by WritingItLikeTHis so that the unique
> personality of the C/C++ programmer comes out in distinctive way from
> the rest of the programmer community at large.

I'm confused.  If most C/C++ programmers have runTogetherFunctionNames,
how can it be "distinctive", "different", and "anti-establishment"?

[snip]

> I don't think I've seen Ada code written the C/C++ way, and I dont
> think I've seen C/C++ code writeen the Ada way. I've seen code
> written like_this_with_no_upper_case which is C/C++ code, but that
> was very rare. 

I've seen both styles in both languages.

[snip]

> Well, thank you in advance for your opinion on this subject.
> nasser

My opinion is quite simple -- I prefer runTogether over
using_underscore_characters because 'shift-_' is slower to type than
runTogether.  I don't feel that runTogether is hard to read at all, so I
continue to use it.  

BTW, *either* style is much easier to read, IMO, than
ALL_UPPERCASE_WITH_UNDERSCORES.

Michael
-- 
Michael Hartwig
Lockheed Martin Federal Systems, Owego, NY

Re: Language Choice and Coding style

[Theodore E. Dennison]

Nasser Abbasi wrote:
> 
> I'd like to know why do C and C++ programmer
> 
> pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers
> Write_In_Clear_And_Nice_Way_Like_This ??

It's a little known fact that the underscore wasn't invented until
1984.
:-)

> While the Ada programmers seem to be more of the conservative type,
> the type who would never go faster than 55 mph even in the middle of dead
> valley where there is no traffic for miles on stretch, the type who
> would never color their hair or do something anti-establisment and so
> this reflect in the Long_And_Slow_But_Sure_Way_They_Write_The_Code.

Hmm. You've obviously never seen me drive. :-)

I'll have to admit though, I am the type of person who ALWAYS uses
his turn signal, even when there is no one around. And there is
nothing that pisses me off more than when other drivers don't use
their turn signal. Perhaps there is some sort of relation here.

> I don't think I've seen Ada code written the C/C++ way, and I dont

Look in the body of any package that comes with a VADS compiler.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Language Choice and Coding style

[Andreas Schoter]

Nasser Abbasi (nasser@apldbio.com) wrote:

: I'd like to research this further and find out how do Cobol and PLi and
: Basic and other programmer write, and see if there is a correlation
: between the emotional/cultural profile of the programmer and between
: the tyep of the language they use and the manner of which they write
: in it.

Well, Prolog has certain typographical conventions: any identifier
beginning with an upper case letter is a variable, so naturally
VariableNames tend to LookLikeThis, whilst any identifier beginning with
a lower case letter is an atom, so by analogy, I guess, atom_names tend
to look_like_this.

Since both idioms exist in the programs that I read/write I actually
don't find either to be harder to read than the other... Oh, and I seem
to have carried the same typographical convention over to my C and SML
programming, except in C, of course, there are also DEFINED_CONSTANTS
and keywords.  Am I glad there's such a thing as colour-coded syntax
highlighting!

And the next question, why am I wasting my time with this?

--
-----------------------------------------------------------------------------
Andreas Schoter                        Discovery and Reasoning in Mathematics
asch@dai.ed.ac.uk                                     University of Edinburgh
http://www.dai.ed.ac.uk/staff/personal_pages/asch/index.html
-----------------------------------------------------------------------------

Re: Language Choice and Coding style

[Rich Maggio]

I found this to be a rather interesting thread.  It is interesting to 
see discussions on "religious" topics.  I can't wait to go and check 
out the OS news groups :-).  I'll bet there is all sorts of fire and 
brimstone over there.

I just wanted to offer my 2 cents worth.

I agree strongly with a comment that was made - there is no point in 
forcing people to drive on the right side of the road, but there is a 
STRONG point for making people drive on the same side of the road.

Basically, what this person was pointing out is the need consistency.  I 
tend to write code that is consistent, though it may not be consistent 
with how others write code.  In my code, I know that all variables that 
begin with a capital letter (i.e. Tone_count) are global.  Someone else 
reading my code may not catch this little nuance.  

Though things like Hungarian notation are cumbersome, I think there is 
definitely a need for it.  There needs to be some consistency in coding 
standards.  This makes it much easier on the poor slob that has to 
maintain the code once the initial development has been done.  

And I agree that more people should use the underscore key.  It sure 
makes it easier to read, especially when function names get out of 
control (i.e. GetCurrentCursorPosition() is just ridiculous.).

Rich Maggio

Re: Language Choice and Coding style

[Samuel Mize]

In article <nh3f3pppsl.fsf@paralysys>,
Nasser Abbasi <nasser@apldbio.com> wrote:

>I'd like to know why do C and C++ programmer 
>
>pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers 
>
>Write_In_Clear_And_Nice_Way_Like_This ??

My best understanding: In The Beginning, all we had was punched cards
and simple teletype interfaces, so everything was all capitals.  That's
all there were.  Also, compiler table-space was tight, so 6-character
or 8-character identifier limits were common.

Once lower case and longer identifiers became available, some people
started writing longer identifiers, while others stayed with the older
trs style.  This is where IdentifiersLikeThis came from.

I think this was first common in Pascal.  I don't think Pascal had
underscores in identifiers, I may be wrong.

Underscores also take a little more effort to type, especially if
you're not a good touch typist.  So, the MixedCase identifier is
still common in some quarters.

One advantage to using underscores avoids the problem of accidentally
reusing an indentifier.  If your compiler is case-insensitive, you can
use both DAndY (D and Y) and Dandy (Dandy) without realizing they're
the same identifier.

If your compiler is NOT case-insensitive, you've got worse nightmares
unless you are very very careful about your cases, or unless you use
all-lower or all-upper (which prevents MixedCase).

The Ada philosophy is that we accept some difficulty for the writer
to make things easier for the reader, so we generally use underscores
in that environment.  (Ada is case-insensitive, so you COULD use
MixedCase, but most style guides discourage it.)

Samuel Mize

Re: Language Choice and Coding style

[Richard A. O'Keefe]

smize@Starbase.NeoSoft.COM (Samuel Mize) writes:
>My best understanding: In The Beginning, all we had was punched cards
>and simple teletype interfaces, so everything was all capitals.  That's
>all there were.  Also, compiler table-space was tight, so 6-character
>or 8-character identifier limits were common.

How soon they forget.
(a) COBOL has always allowed hyphens in identifiers, e.g.
	COMPUTE-WEEKLY-PAYROLL
    It's one of the oldest surviving programming languages.

(b) PL/I had two encodings (the "48-character set" and the "6-character
    set").  The 60-character coding had the underscore.  Where I used it,
    it was considered good PL/I style to use the underscore.  The ANSI
    PL/I standard is 1976, but the language is older than that.

(c) The third oldest computer I have ever seen in operation (the other
    two were an IBM 650 and an IBM 1620) was an IBM 1130.  It had an
    APL keyboard.  APL uses underlines.

(d) Flexowriters!  I've seen a fair bit of Algol 60 code written on
    flexowriters.

(e) Algol 60 and Algol 68 both allowed identifiers of any length, and
    both handled multi-word identifiers by allowing embedded spaces.
    E.g.
	'FOR' EMPLOYEE NUMBER := 1 'STEP' 1 'UNTIL' LAST EMPLOYEE 'DO'
	    WEEKLY PAYROLL[EMPLOYEE NUMBER] := 0;

>Once lower case and longer identifiers became available, some people
>started writing longer identifiers, while others stayed with the older
>trs style.  This is where IdentifiersLikeThis came from.

>I think this was first common in Pascal.  I don't think Pascal had
>underscores in identifiers, I may be wrong.

The old Pascal standard didn't (because the CDC character set lacked 'em).
UCSD Pascal allowed underscores but ignored them.
The new Pascal standard (10206) allows them.

Smalltalk didn't use underscores, because it was developed before the 1967
version of ASCII; the 1963 version of ASCII had a left arrow where the
underscore is now.

>Underscores also take a little more effort to type

That depends entirely on which keybaord you are using.
On the IBM 029 keypunches that I wrote Fortran, Burroughs Algol,
and PL/I in, it was very easy to type underscores.

>especially if
>you're not a good touch typist.  So, the MixedCase identifier is
>still common in some quarters.

This is ludicrous.  It is _harder_ to type 
	FooBarUgh
(because it requires *three* case shifts) than
	foo_bar_ugh
(because it requires only *two* case shifts).  And in an age of mutable
keymaps it is even sillier.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Language Choice and Coding style

[Samuel Mize]

In article <4r7pvr$sh6@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>smize@Starbase.NeoSoft.COM (Samuel Mize) writes:
...
>>Underscores also take a little more effort to type
...
>>especially if
>>you're not a good touch typist.  So, the MixedCase identifier is
>>still common in some quarters.
>
>This is ludicrous.  It is _harder_ to type 
>	FooBarUgh
>(because it requires *three* case shifts) than
>	foo_bar_ugh
>(because it requires only *two* case shifts).  And in an age of mutable
>keymaps it is even sillier.

I didn't say it wasn't silly.  Many poor typists avoid at all costs
getting that forefinger off the home key.  *I* can type underlines
without looking away from the screen, and apparently so can you.

But some people really do resist change for such trivial reasons.
Or at least, this is how they justify not changing their habits.

Samuel Mize

Re: Language Choice and Coding style

[Robert Dewar]

The endless discussion over what form of identifiers is easiest to read
is a bit silly.

In practice what is easiest to read is what you are used to. I used to like
the 83 RM style of all caps because I was used to it, and it was easiest
to read, because of this familiarity. Then I switched to mixed upper/lower
case with underlines, and now that seems the easiest to read.

This familiarity factor argues for consistency, and one of the nice things
about COBOL for example is that absolutely EVERYONE has the same identifier
style.

In Ada with Ada 95, there seems to be a real consensus developing for
use of Mixed_Case_Identifiers_With_Underscores, and that seems a good
thing (that a consensus is developing). I think this consitency is much
more important than odd individual preferences, and I would encourage
people NOT to develop peculiar idiosyncratic conventions, it will just
make your code harder to read for other people.

Re: Language Choice and Coding style

[++ robin]

	ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

	>smize@Starbase.NeoSoft.COM (Samuel Mize) writes:
	>>My best understanding: In The Beginning, all we had was punched cards
	>>and simple teletype interfaces, so everything was all capitals.  That's
	>>all there were.  Also, compiler table-space was tight, so 6-character
	>>or 8-character identifier limits were common.

	>How soon they forget.
	>(a) COBOL has always allowed hyphens in identifiers, e.g.
	>	COMPUTE-WEEKLY-PAYROLL
	>    It's one of the oldest surviving programming languages.

	>(b) PL/I had two encodings (the "48-character set" and the "6-character
---								     ?
---That's the 60-character set.

	>    set").  The 60-character coding had the underscore.  Where I used it,
	>    it was considered good PL/I style to use the underscore.  The ANSI
	>    PL/I standard is 1976, but the language is older than that.

---Yes, that's about 1966 when it first came out.

	>(c) The third oldest computer I have ever seen in operation (the other
	>    two were an IBM 650 and an IBM 1620) was an IBM 1130.  It had an
	>    APL keyboard.  APL uses underlines.

	>(e) Algol 60 and Algol 68 both allowed identifiers of any length, and
	>    both handled multi-word identifiers by allowing embedded spaces.
	>    E.g.
	>	'FOR' EMPLOYEE NUMBER := 1 'STEP' 1 'UNTIL' LAST EMPLOYEE 'DO'
	>	    WEEKLY PAYROLL[EMPLOYEE NUMBER] := 0;

	>>Once lower case and longer identifiers became available, some people
	>>started writing longer identifiers, while others stayed with the older
	>>trs style.  This is where IdentifiersLikeThis came from.

	>>I think this was first common in Pascal.  I don't think Pascal had
	>>underscores in identifiers, I may be wrong.

	>The old Pascal standard didn't (because the CDC character set lacked 'em).
	>UCSD Pascal allowed underscores but ignored them.
	>The new Pascal standard (10206) allows them.

	>Smalltalk didn't use underscores, because it was developed before the 1967
	>version of ASCII; the 1963 version of ASCII had a left arrow where the
	>underscore is now.

	>>Underscores also take a little more effort to type

	>That depends entirely on which keybaord you are using.
	>On the IBM 029 keypunches that I wrote Fortran, Burroughs Algol,
	>and PL/I in, it was very easy to type underscores.

	>>especially if
	>>you're not a good touch typist.  So, the MixedCase identifier is
	>>still common in some quarters.

	>This is ludicrous.  It is _harder_ to type 
	>	FooBarUgh
	>(because it requires *three* case shifts) than
	>	foo_bar_ugh
	>(because it requires only *two* case shifts).  And in an age of mutable
	>keymaps it is even sillier.

Re: Language Choice and Coding style

[Russel A Hill]

In article <JSA.96Jun26141502@organon.com>, jsa@organon.coms says...
>OKAnyParticularReasonWhyYourPostIsNotInThisSortOfSquashedTextStyleThatYou
>ThinkReadsSoMuchBetter?

Get a life Jon.  I type this way because it commnitactes well.  Out compiler 
Technology isn't suuffieicently advbanced to handle:
 
  Loop Control Variable = Initial Value

Unless you propran in FORTRAN, of course.  But that has its own drawbacks.  So 
what works well and is compatible  with currently available compilers...

Both of the below work.

  LoopControlVariable = InitialValue

  Loop_Control_Variable = Initial_Value

I prefer the former.  It reads better.  Whichever you use, use it wisely.  If 
you were to code the following on my project I'd fire you on the spot.

Loop_Control_Variable_For_Iterating_Whosit_Through_Whatchamacallit = 1

Hyperbole has it's place, so long as you hit the mark.


-- 
Russel A. Hill / Virtual Genetic Systems
2981 Highway 66; Ashland, OR 97520
Voice: 541-488-8906 / 800-460-8064  Fax: 541-488-0039
E-mail: rahill@mind.net             URL: http://www.mind.net/virtualgenetics/

Re: Language Choice and Coding style

[Robert Dewar]

Russel said

"Get a life Jon.  I type this way because it commnitactes well.  Out compiler
Technology isn't suuffieicently advbanced to handle:

  Loop Control Variable = Initial Value"

Well I don't know if we are commnitacting clearly, but if I understand
your point, it is in fact the case that Algol 60 allowed spaces in
identifiers, and this was common usage (see the Algol 60 report for
examples).

Re: Language Choice and Coding style

[Russel A Hill]

In article <dewar.836270301@schonberg>, dewar@cs.nyu.edu says...
>Well I don't know if we are commnitacting clearly, but if I understand
>your point, it is in fact the case that Algol 60 allowed spaces in
>identifiers, and this was common usage (see the Algol 60 report for
>examples).

Point taken.  I don't pretend to know Algol 60 or keep up on every language 
spec published.  In the C++ world, spaces are not allowed in identifier names, 
therefore we must resort to other mechanisms to enhance readability.  

-- 
Russel A. Hill / Virtual Genetic Systems
2981 Highway 66; Ashland, OR 97520
Voice: 541-488-8906 / 800-460-8064  Fax: 541-488-0039
E-mail: rahill@mind.net             URL: http://www.mind.net/virtualgenetics/

Re: Language Choice and Coding style

[Richard A. O'Keefe]

rahill@mind.net (Russel A Hill) writes:
>Get a life Jon.  I type this way because it commnitactes well.  Out compiler 
>Technology isn't suuffieicently advbanced to handle:
> 
>  Loop Control Variable = Initial Value

Sorry, but this is rubbish.  Algol 60 and Algol 68 both allowed this.
As an exercise, I once wrote a version of the Prolog read/1 command
that allowed embedded blanks in identifiers, and IT WAS DEAD SIMPLE.
"Our compiler technology" has been "sufficiently advanced" for more
than 30 years.

It isn't even a "compiler technology" issue; it's only a "lexical analysis"
issue.  There is no problem dealing with a mix of identifiers, operator
symbols, and punctuation marks.  The only problem is when you have keywords
that look like identifiers.  Algol 68 explored the "stopping" possibilities
reasonably thoroughly.  One simple method, for example, is "case strop":
keywords are in upper case, everything else in lower case.  So one might
write

    FOR i FROM LB sensor table TO UB sensor table DO
	has overflowed OF sensor table [i] := FALSE
    OD

This is not rocket science.  Another technique is to use a special
prefix character:  IMP used '%', Algol 68 used '.':
    .For i .from .lb sensor table .to .ub sensor table .do
	Has overflowed .of sensor table [i] := .false;
    .Od
(and with the full stop being in the same shift as the lower case letters,
this cannot be said to be hard to type.  Indeed, I was surprised to find
just how easy it is.)

I note comp.lang.c and comp.lang.c++ in the newsgroups line.  Let's see
what changes to C would be needed to allow embedded blanks in identifiers.
Declarations can have lots of words run together, e.g. unsigned long int foo.
To handle that, we'll borrow Pascal/Fortran 90 declaration syntax.
	<id list> : <type>
will be a variable declaration, and
	<header> : <type> <block>
will be a function definition.  There is one word operator: sizeof.
We'll use function call syntax for that, which is already legal anyway.
A labelled statement can be told from a declaration by the fact that the
keywords that begin a <type> cannot begin a <statement> in revised syntax.

Here is part of a file comparison program:

void print_line(long n, char const *line) {
    printf("%7ld %s", n, line);
    if (0 == strchr(line, '\n'))
	printf("...\n");
}

void compare_streams(FILE *f1, FILE *f2) {
    char line1[LINE_BUFF_SZ];	/* line read from f1 */
    char line2[LINE_BUFF_SZ];	/* line read from f2 */
    char const *p1;		/* set to NULL at end of f1 */
    char const *p2;		/* set to NULL at end of f2 */
    long n;			/* current line number */

    n = 0;
    do {
	n++;			/* count attempts to read from f1 */
	p1 = fgets(line1, sizeof line1, f1);
	p2 = fgets(line2, sizeof line2, f2);
    } while (p1 != NULL && p2 != NULL && strcmp(p1, p2) == 0);

    if (p1 != NULL && p2 != NULL) {
	/* neither file has ended yet; the lines must disagree */
	printf("files differ\n");
	print_line(n, line1);
	print_line(n, line2);
    } else
    if (p1 != NULL) {
	/* file1 has not ended, but file2 has */
	printf("first file longer\n");
	print_line(n, line1);
    } else
    if (p2 != NULL) {
	/* file2 has not ended, but file1 has */
	printf("second file longer\n");
	print_line(n, line2);
    }
    /* no output is produced if both files were the same */
}

In revised C syntax:

print line(n: long, line: char const *): void {
    printf("%7ld %s", n, line);
    if (0 == find char in string(line, '\n'))
	printf("...\n");
}

compare_streams(file one, file two: FILE *) void: {
    line one, line two: char[LINE BUFF SZ];
    p one, p two: char const *;
    n: long;

    n = 0;
    do {
	n++;
	p one = f get string(line one, sizeof(line one), file one);
	p two = f get string(line two, sizeof(line two), file two);
    } while (p one != NULL && p two != NULL
          && string compare(p one, p two) == 0);

    if (p one != NULL && p two != NULL) {
	printf("files differ\n");
	print line(n, line one);
	print line(n, line two);
    } else
    if (p one != NULL) {
	printf("first file longer\n");
	print line(n, line one);
    } else
    if (p two != NULL) {
	printf("second file longer\n");
	print_line(n, line two);
    }
}

Except for declaration syntax, very little changes.  What conclusion does
this lead to?  A blindingly obvious one:

    it is not our *compiler technology* that forbids embedded blanks
    in identifiers, it is our *programming language standards*.
    If we wanted embedded blanks, we could have them.

All you have to do is design your language so that
	... <identifier> <identifier> ...
	... <keyword> <identifier> ...
	... <identifier> <keyword> ...
cannot occur, and then you don't even need stropping.	

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Language Choice and Coding style

[Jon S Anthony]

In article <4r7cnq$g57@sun.quiknet.com> rahill@mind.net (Russel A Hill) writes:

> In article <JSA.96Jun26141502@organon.com>, jsa@organon.coms says...
> >OKAnyParticularReasonWhyYourPostIsNotInThisSortOfSquashedTextStyleThatYou
> >ThinkReadsSoMuchBetter?
> 
> Get a life Jon.  I type this way because it commnitactes well.  Out compiler 
> Technology isn't suuffieicently advbanced to handle:
>   Loop Control Variable = Initial Value

Um, I think you need to lighten up a bit - my comment was tongue in
cheek.  I really didn't think it needed a smiley.  BTW, you are wrong
that compilers can't handle variable names (e.g.) that are composed
with blanks.  Why do you think otherwise?


> Unless you propran in FORTRAN, of course.  But that has its own drawbacks.

Nope, not only Fortran (which is not a particularly good example)


> you were to code the following on my project I'd fire you on the spot.
> 
> Loop_Control_Variable_For_Iterating_Whosit_Through_Whatchamacallit = 1

So?  What's the relevance in this context?


> Hyperbole has it's place, so long as you hit the mark.

You missed...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Language Choice and Coding style

[Mark Eichin]

Intriguing.

>     p one, p two: char const *;

Interestingly enough, this eliminates the common mistake of using

	char const *p1, p2; /* A */
when 
	char const *p1, *p2; /* B */

is what is intended. (Yes, I know you'll get a compiler error with A
in most actual uses, but you can construct cases where you don't...)

One obvious nit is the C bitfield specifier... but it turns out that
it is easy to leave unchanged from context (by putting it in the type,
not the variable... ie:
	int j1:1;
becomes
	j one: int: 1;
with no ambiguity.)

The conclusion
>    it is not our *compiler technology* that forbids embedded blanks
>    in identifiers, it is our *programming language standards*.

is interesting, because the C standard was explicitly an attempt to
codify existing practice in what had begun as a low-level language
design, and not redesign it.  C++ is correspondingly limited to the
same thing by it's C heritage.  Ada doesn't have these particular
constraints... so were spaces in identifiers simply not considered
[since noone else had used them in 30 years] or where they
deliberately omitted?

					_Mark_ <eichin@cygnus.com>
					Cygnus Support, Eastern USA

Re: Language Choice and Coding style

[Nasser Abbasi]

   From: maggior@world2u.com (Rich Maggio)
   Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
   Date: 29 Jun 96 22:21:57 GMT

  ... snip..

   Basically, what this person was pointing out is the need consistency.  I 
   tend to write code that is consistent, though it may not be consistent 
   with how others write code.  In my code, I know that all variables that 
   begin with a capital letter (i.e. Tone_count) are global.  Someone else 
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   reading my code may not catch this little nuance.  


One should not be using global variables to start with !

   Though things like Hungarian notation are cumbersome, I think there is 
   definitely a need for it.  

I dont think there is a need for it. It makes the code harder to read
to start with, and it does not add anything to understanding the
algorithm itself. IMHO.

   There needs to be some consistency in coding standards. This makes it 
   much easier on the poor slob that has to maintain the code once the 
   initial development has been done.  

good point. Good documentations helps the most here too.

nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 1.e4 !!   1-0 )

Re: Language Choice and Coding style

[steidl]

In <nh3f3a5qwm.fsf@paralysys>, nasser@apldbio.com (Nasser Abbasi) writes:
>
>   From: maggior@world2u.com (Rich Maggio)
>
>   Though things like Hungarian notation are cumbersome, I think there is 
>   definitely a need for it.  
>
>I dont think there is a need for it. It makes the code harder to read
>to start with, and it does not add anything to understanding the
>algorithm itself. IMHO.

Hungarian notation seems self-contradictory to me.  Its proponents
claim that it is a part of good coding style (or at least most of them
do ;-)).  Its purpose is to make it easy to tell at a glance what a
variable's type is.  The underlying assumption, then, seems to be that
there are just too many variables for the reader of the program to keep
track of and/or the definition of the variable is too far away to be
quickly glanced at.  If either or both of these is the case, isn't it
very likely that the code is in bad need of decomposition?  (I.e.,
another part of good coding style is being ignored?)  [I suppose
another case for hungarian notation would be for global variables,
since the definition of the variable is - by definition :) - not
local.  But then that would just be another violation of generally
accepted good coding style.]  I *might* be able to see an argument
for the use of hungarian notation for functions, since most development
environments do not let you easily glance it its definition.  (But
even for functions, I would still not personally want to use hungarion
notation - I would rather buy/build a better editor which *does* let
you view the definition at a glance).  Of course, what would be really
cool is if a code editor had an option that let you turn type-info
on and off (i.e. it would space out your code a little more so that it
could display the type of every variable and function just below its
use) - since I think that would make both camps happy.  (Or you could
use Xerox PARC's "lens" idea for this.)

Can someone come up with a case where:
   1. hungarian notation is needed for variables
   2. (1) is not solved by some other common good coding style method
   3. the case is not ultra-specific (i.e. it justifies hungarian
      notation as being a general good coding style method)


-Jeff


BTW, I tend to declare things in alphabetical order for just this
reason - to keep it down to a glance instead of an O(N) search.

Re: Language Choice and Coding style

[Samuel Mize]

In article <4re0la$qk6@news.ld.centuryinter.net>,
 <steidl@centuryinter.net> wrote:
>In <nh3f3a5qwm.fsf@paralysys>, nasser@apldbio.com (Nasser Abbasi) writes:
>>
>>   From: maggior@world2u.com (Rich Maggio)
>>
>>   Though things like Hungarian notation are cumbersome, I think there is 
>>   definitely a need for it.  

I know it's been discussed here before, so please don't post it -- but
could someone please email me what Hungarian notation is, and/or a
reference to any article or book about it?  Thanks.

Samuel Mize

Re: Language Choice and Coding style

[N. L. Sizemore]

steidl@centuryinter.net wrote (at end of very cogent argument):
> 
> Can someone come up with a case where:
>    1. hungarian notation is needed for variables
>    2. (1) is not solved by some other common good coding style method
>    3. the case is not ultra-specific (i.e. it justifies hungarian
>       notation as being a general good coding style method)
> 
> -Jeff
> 
> BTW, I tend to declare things in alphabetical order for just this
> reason - to keep it down to a glance instead of an O(N) search.

	As a possible example meeting the stated desiderata I would offer certain types of transaction 
processing code.  Assume:

	-	A three-tier c/s architecture
	-	Control under a transaction monitor/manager
	-	A complex retrieval, i.e. , a data structure involving joins from several disparate data 
sources
	-	a (potentially) heavy transaction workload
	-	Coding for transaction logic (aka 'business rules') at the 2nd tier, i.e., the transaction 
server/router

	Under these assumptions reasonable code style requirements might include:

	-	use local copies of data elements prior to 'prepare to commit'
	-	avoidance of other than absolutely necessary context shifts, e.g., call/returns, RPCs, etc.
	-	in line documentation of data types and/or sources which are defined externally

	An admittedly constrained example but not, I think, infeasible.
-- 
------------------------------------------------------------
 || Come ride The River ------- http://www.theriver.com/ ||
------------------------------------------------------------

Re: Language Choice and Coding style

[steidl]

In <31DEF0FC.4FDC@theriver.com>, "N. L. Sizemore" <bolshev@theriver.com> writes:
>steidl@centuryinter.net wrote (at end of very cogent argument):
>> 
>> Can someone come up with a case where:
>>    1. hungarian notation is needed for variables
>>    2. (1) is not solved by some other common good coding style method
>>    3. the case is not ultra-specific (i.e. it justifies hungarian
>>       notation as being a general good coding style method)
>
>	As a possible example meeting the stated desiderata I would offer certain types of transaction 
>processing code.  Assume:

OK, I'm not a DB man, so I'll state my assumptions about your assumptions
so that you can check to determine if my subsequent responses might be
totally from left field:

>	-	A three-tier c/s architecture

c/s == client/server (took me minute... like I said, Self != DB_programmer)
Is the client a tier, the server a tier, and the transaction
manager/monitor a tier inbetween?  [I am assuming that you are using a
three-tier architecture in your example because it necessitates your first
requirment below (i.e. local copies of data elements) in order to avoid
unnecessary RPCs).]

>	-	Control under a transaction monitor/manager

I assume this is for reliability (whole transaction completes or
doesn't complete) and logging purposes.  Or does it also allow/disallow
transactions to pass?  [I'm not sure what this assumption of yours
provides beyond your first one, so maybe I'm missing something here.]

>	-	A complex retrieval, i.e. , a data structure involving joins from several disparate data 
>sources
>	-	a (potentially) heavy transaction workload

At least know what those two mean. ;-)

>	-	Coding for transaction logic (aka 'business rules') at the 2nd tier, i.e., the transaction 
>server/router

Shoot, I know I've read about business rules somewhere...
something to do with coding company policy into your program I think.
[I can't remember exactly what this is, but I am assuming that the
reason you included this is because it would tend to make your
functions more complex.]

>	Under these assumptions reasonable code style requirements might include:
>
>	-	use local copies of data elements prior to 'prepare to commit'

I'm not sure how hungarian notation makes this any easier to do.
(My responses to your other two requirements may provide you with some
justification for this response of mine.)

>	-	avoidance of other than absolutely necessary context shifts, e.g., call/returns, RPCs, etc.

It may be necessary for the executable to be implemented using
large functions (and loop unrolling and tedious instruction
scheduling etc.) in order to be efficient, but that is no reason
that the programmer should be subjected to the same.  Luckily,
inline functions avoid the calls/returns without requiring us to
write huge functions (and thus lose the benefits of decomposition).

And the local copies of the data elements are already sufficient to
avoid unnecessary RPCs, right?

>	-	in line documentation of data types and/or sources which are defined externally

Well, I was only asking for hungarian use for variables, but
I totally ignored types in my original post - so here's my
opinion of them:  The whole reason a Type/Class is created is
to provide data abstraction of some kind.  The user should not
need to know what underlying built-in types the Type/Class is
composed of.  And since the user should not need to be at
all concerned with the underlying types, the Type/Class name
should certainly not carry around the baggage of hungarian
notation.

If by "sources" you are referring to source-code (functions), then
hungarian notation may be useful if your code editor does not have
a feature which lets you quickly examine the return type and
argument types.  (Although, including all of the argument types
for a procedure in some type of compound hungarian notation could
get quite lengthy - and would almost be a suitable replacement for
C++ name mangling, which isn't all that flatterring for hungarian
notation. :-)

>	An admittedly constrained example but not, I think, infeasible.


I think that what your above assumptions and requirements are defining
here is not limited to just database operations.  I think that you are
basically saying:
   "What if
      - My program includes certain expensive operations (such as RPCs)
        which are alleviated by having local copies of variables.
      - My program is large and complex.
      - My program needs to be efficient."

Welcome to the club! ;-)

Many programmers have to deal with this same set of obstacles.  So,
at least in that sense, your example really isn't all that constrained.
But I'm not able to see why it justifies hungarian notation.  Maybe
you could provide a more explicit correlation between your example
and the need for hungarian notation and/or correct any relevant
mistakes in my assumptions/responses.

I have given this subject a little more thought (hungarian notation
in general, not specifically in relation to your example), and have
come to a couple more conclusions.  First, I retract my opinion on
the use of hungarian notation for function names [I can do that,
check my .sig :-)].  I think that the paragraph which gives my
reasons for not using hungarian notation for types can be extended
to also cover variables and functions.  Well written code should not
only use the principle of abstraction for its types/classes (thus
removing the need for hungarian notation for types), but should
also apply this to its variables and functions.  For example, in some
code that I recently managed, I was very strict about the naming of
variables.  A client's record number was always stored in the
variable "ClientRecNum" (RecNum was one of the very few standard
abbreviations I allowed), or a variation on that (such as
"NewClientRecNum", etc.)  It did not matter whether the record number
was implemented as a signed int, or an unsigned long, that is not
relevant.  The variable's name can provide a level of abstraction just
as a data type can.  Note that I didn't allow the name "Client" for a
client's record number since that results in the variable appearing to
have a different "interface" than it actually did.  For the same reason
"ClientRec" was also not allowed.  And where a client record number was
actually the record number of the first client in a list of clients,
"ClientRecNum" was not allowed and instead "ClientList" was required.
I think if a variable accurately indicates what it is at the proper
level of abstraction, there is no need to prefix its name with the
underlying types.  It seems to me that doing so would only hurt the
maintainability of the code.


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

Re: software engineering and the notion of authorship

[Robert Dewar]

Simon says

  "We have a similar story here, a well known and extremely good assembler =
  programmer wrote a large (>800 line) assembler package with one comment, =
  next to a Jump-If-Equal statement he wrote the single comment "Jump here =
  if not equal" - Wonderful!"


Of course, the fault lies here not with the programmer, but with the
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely good
assembler programmer" who would write a package of this size with no
comments. The real fault lies with a manager who did not realize this
and who tolerated such nonsense.

Re: software engineering and the notion of authorship

[Robert Dewar]

"We have a similar story here, a well known and extremely good assembler =
programmer wrote a large (>800 line) assembler package with one comment, =
next to a Jump-If-Equal statement he wrote the single comment "Jump here =
if not equal" - Wonderful!"


Of course, the fault lies here not with the programmer, but with he
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely god
a

Re: software engineering and the notion of authorship

[Hugh Dunne]

Simon Johnston <skj@ACM.ORG> wrote:

>I had to maintain a large chunk of code which had only one comment =
>(well,
>I tell a lie, there were two: a commented out chunk of code -- with no
>reason -- and the copyright notice) and a lot of one or two letter
>identifiers.  And code reviews were not a political practicality with
>that piece of code:  it had been written by the _founder_ of the
>company before I joined.  And he had left.
>
>We have a similar story here, a well known and extremely good assembler =
>programmer wrote a large (>800 line) assembler package with one comment, =
>next to a Jump-If-Equal statement he wrote the single comment "Jump here =
>if not equal" - Wonderful!

Some of the (few) comments seen in the source code of a certain
Ada compiler vendor's run time system:

	"Go backwards or die!!!"
	"Stupid Ada!"
-- 
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
The above are strictly my own personal opinions  | dunneh@lhd.logica.com
and in no way reflect the opinions of Logica.    | +44 171 446-1608