Searching \ for '[PIC]: or [EE]: C syntax question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'or [EE]: C syntax question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: or [EE]: C syntax question'
2001\10\26@102103 by Mark Skeels

picon face
Hi, List.

Out ofnecessity, I continue to study C.

On page 105 of "The C Programming Language", there are two versons of
function strcpy:

version 1:
void strcpy(char *s, char *t)
{
   while ((*s = *t) != '\0') {
       s++;
       t++;
   }
}

version 2:
void strcpy(char *s, char *t)
{
   while ((*s++ = *t++) != '\0') {
       ;
   }
}

Before the second version, we read the following statements...

"Experienced C programmers would prefer..."

My question is, could you explain why it is good to move both the asignment
operation and the increment operation into the while test portion?

As a Pascal programmer, I was taught that anything that makes the program
more readable is good. This does not seem to qualify on that count. What's
more, it seems to muddle the entire while loop by mixing assignment and
increment with the test portion.

Also, what is the logic behind understanding the actual test in the while
loop? I can't understand from the syntax exactly what is being compared to
'\0'. Is it *s? *t? If so, why?

Comments?

Mark Skeels
Engineer
Competition Electronics
spam_OUTmeskeelsTakeThisOuTspamearthlink.net

Soli Deo Gloria!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@105818 by Dale Botkin

flavicon
face
> Out of necessity, I continue to study C.

Yeah, me too.

{Quote hidden}

It's testing (*s++ = *t++) compared to '\0'.  In effect, it copies *t to
*s then compares to 0, then increments.  But why really would
"experienced" C programmers like the second form better?  Well, less
typing...  that's a big plus...  they do the exact same thing, and CCS
compiles both to the same size.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@112329 by Gerhard Fiedler

flavicon
face
At 09:56 10/26/2001 -0500, Dale Botkin wrote:
> > version 2:
> > void strcpy(char *s, char *t)
> > {
> >     while ((*s++ = *t++) != '\0') {
> >         ;
> >     }
> > }
> >
>It's testing (*s++ = *t++) compared to '\0'.  In effect, it copies *t to
>*s then compares to 0, then increments.

When exactly it increments is not defined (which can chase you at times).
It just says that the data used in the expression is taken from the
location where t or s point to before the increment, and that after this
expression got evaluated, t and s point to the next value -- that's all.
What exactly the compiler does can vary from implementation to
implementation; you only know that it increments at some point within
certain limits (which are defined). For example, it could increment at the
beginning of the statement and keep the old pointer value in a temp storage
for the actual access.

>Well, less typing...  that's a big plus...  they do the exact same thing,
>and CCS
>compiles both to the same size.

Besides from some people priding themselves to write as compact as posible
(and as difficult to understand as possible -- there are contests who
writes the most obscure C code! :), I like it when I can see a lot of
functionality in a screenful of code. So, as long as it doesn't hamper
readability and maintainability, I try not to use more lines as necessary.

ge

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@113603 by Simon Stirley

flavicon
face
[snip]
>
> It's testing (*s++ = *t++) compared to '\0'.  In effect, it
> copies *t to
> *s then compares to 0, then increments.  But why really would
> "experienced" C programmers like the second form better?

Well I've been using C and C++ for 12 years so I probably qualify as
'experienced' :)
I don't prefer the second at all .. it looks horrible. In fact I wouldn't
even use the first .. due to the progress in compiler technology in recent
years most code that _does_ the same will equate to the same (maybe not in
the PIC world, agreed) so the easier you can make it to understand the
better. The 2 examples given are not as 'bomb-proof' as I would like,
especially seeing as C doesn't support exception handling. I would do
something more like -

void
strcpy(char* s, char * t)
{
 // first check they are both valid
 if (!s || !t)
   return;

 // now, while the source in non-zero and the target is valid memory ..
 while (*s && t)
   {
     *t = *s;
     s++;
     t++;
   }
}

Loads of whitespace, loads of indenting, easy to read - all good habits if
you ever work in a team or on code that someone else will _ever_ look at ..
it will all evaluate to practically the same thing. If you really want
memory or speed efficiency then do it in assembler anyway (or edit the
assembler that the C compiler generates !)

> Well, less
> typing...  that's a big plus...  they do the exact same thing, and CCS
> compiles both to the same size.

Less typing isn't always good .. I can type more code faster than I can
debug well hidden mistakes :)
Imagine having

while ( ( *t == *s ) != '\0')

.. in the code. Spot the mistake first time did you ? didn't think so ..
Also the '\0' is a bit superfluous, not that it makes any difference either
- the compiler will generate a zero for it anyway.

> Dale

HTH, Simon.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@121047 by Douglas Wood

picon face
Mark,

> My question is, could you explain why it is good to move both the
asignment
> operation and the increment operation into the while test portion?

It's not so much a "good"thing as it is a consise thing. The second example
allows the "experienced" C programmer to see everyhting that's going on in
one fell swoop. There are two camps here: the ones who want to see
everything on the least lines possible and those that would opt for example
#1 where everything is a little easier to see. (I would offer a third
example where the assigment statement, *s = *t, is taken out of the while()
statement and given a line of it's own.) Any good compiler (subjective, I
know) should be able to generate roughly the same amount of code for all
(two/three?) examples.

> Also, what is the logic behind understanding the actual test in the while
> loop? I can't understand from the syntax exactly what is being compared to
> '\0'. Is it *s? *t? If so, why?

Well, since the char at the location pointed to by t is placed into the
location pointed to by s, they both should now contain the same data. So it
doesn't matter which location gets compared to zero.
(\0).

Douglas Wood
Software Engineer
.....dbwoodKILLspamspam@spam@kc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@121650 by Simon Stirley

flavicon
face
> > Also, what is the logic behind understanding the actual
> test in the while
> > loop? I can't understand from the syntax exactly what is
> being compared to
> > '\0'. Is it *s? *t? If so, why?
>
> Well, since the char at the location pointed to by t is
> placed into the
> location pointed to by s, they both should now contain the
> same data. So it
> doesn't matter which location gets compared to zero.
>  (\0).

I thought it was the outcome of the = operation that was compared in a
compound statement like this .. ie. the operation was successful. In this
example I would expect the target of the copy to be null characters anyway,
otherwise you'd be over-writing some other string.

Simon.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@131038 by Douglas Wood

picon face
Simon,

The "outcome" of the '=' operation is to place the contents of the
expression on the right side of the '=' into the location given by resolving
the expression on the left side. No other processing or testing is
performed; it is simply an assignment statement. However, in this example
the "result" of the assigment is compared to '\0'; since after the
assignment *s = *t both the locations pointed to by the pointers s and t
have the same data in them, it matters not which one gets used for the
comparison test against '\0'.

No, in this example, the character that's being copied (from the location
pointed by t to the location pointed to by s) is being tested to for that
character is the C string termination char '\0'. If it is, it signals the
end of the string (char by char) copy operation.

Douglas Wood
Software Engineer
dbwoodspamKILLspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\10\26@135329 by Byron A Jeff

face picon face
On Fri, Oct 26, 2001 at 09:40:38AM -0500, Mark Skeels wrote:
{Quote hidden}

It's more compact. C was designed in an era when processing power was limited,
memories were small, and optimizing was still in its infancy. A non-optimizing
compiler would generate more code for the first than the second, making it
bigger and slower. C programmers of the '70 were speed freaks. Truth be told
an experienced C programmer would have written it as:

void strcpy(char *s, char *t)
{
  while (*s++ = *t++);
}

simply omitting the compare to zero because the loop would complete after the
terminating NULL was copied.

All of this is superfluous in more of today's compilers. Almost every one would
optimize the code into the third example.

>
> As a Pascal programmer, I was taught that anything that makes the program
> more readable is good. This does not seem to qualify on that count. What's
> more, it seems to muddle the entire while loop by mixing assignment and
> increment with the test portion.

This isn't Pascal. C's primary tenent has always been that the programmer knows
what they are doing. So it sprinkles lots of different optimizing techniques
into the language for folks to take advantage of. This cultural trait persists
because there's a hoard of legacy programs and legacy programmers who continue
to generate tight, yet cryptic code.

But again the point is moot. Feel free to code in whatever manner you feel
comfortable. But be aware that you'll need to understand all of the tricks
in order to understand a large body of the code that's out there.

>
> Also, what is the logic behind understanding the actual test in the while
> loop? I can't understand from the syntax exactly what is being compared to
> '\0'. Is it *s? *t? If so, why?

Assignment is an operator in C, not a statement. The value of an assignment
is the value that is assigned. For example:

i = 3;

Places the value 3 into i, it also produces a value of 3 as the result. So
code like:

j = 2 + (i = 3);

Would assign i with 3, and then add the result (3) to 2 and assign that to j.

So to answer your question, the value of *t is the result of the assignment.
Also note that t moves from one space to the next. Since the increment is after
the t, it occurs after the value of *t is obtained.

>
> Comments?

There are different ways of doing it. Do what you feel comfortable with, as
most modern optimizing compilers will take care of generating efficient code.

It's just different cultures.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@150638 by Olin Lathrop

face picon face
> "Experienced C programmers would prefer..."
>
> My question is, could you explain why it is good to move both the
asignment
> operation and the increment operation into the while test portion?
>
> As a Pascal programmer, I was taught that anything that makes the program
> more readable is good. This does not seem to qualify on that count. What's
> more, it seems to muddle the entire while loop by mixing assignment and
> increment with the test portion.

I agree with you completely.  Just because you CAN do something in C in one
line doesn't mean you should.  The biggest long term cost of software is
maintenance, so most of the code should be optimized for clarity and to
reduce the chance someone might overlook a detail.  Most of this comes at no
cost in cycles or code space because the compiler rearranges things
internally into sequential operations anyway.  It's just a matter of laying
out the source code in an easy to follow manner, and of course including
good comments.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@150802 by Pfaff, John

flavicon
face
The result of an '=' operation is what was assigned.  For example:
       ((x = 3) == 3)
is true.

Simon Stirley wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@153608 by Dale Botkin

flavicon
face
> > As a Pascal programmer, I was taught that anything that makes the program
> > more readable is good. This does not seem to qualify on that count. What's
> > more, it seems to muddle the entire while loop by mixing assignment and
> > increment with the test portion.
>
> I agree with you completely.  Just because you CAN do something in C in one
> line doesn't mean you should.  The biggest long term cost of software is
> maintenance, so most of the code should be optimized for clarity and to
> reduce the chance someone might overlook a detail.  Most of this comes at no
> cost in cycles or code space because the compiler rearranges things
> internally into sequential operations anyway.  It's just a matter of laying
> out the source code in an easy to follow manner, and of course including
> good comments.

So would you be as comfortable with one line of cryptic-looking code with
five lines of comments explaining it, or five lines of perfectly clear
code with one line of comments?  Or five and five?  Personally I tend
toward the first:

void strcpy (char *s, char *t) {
    // This will copy from *t into *s, incrementing each
    // pointer and looping until a null is encountered in
    // *t.  Once we see a null, *s = *t evaluates to 0
    // and the while loop ends.
    while (*s++ = *t++);
}

I tend to do it that way for a couple of reasons -- first, since I still
consider myself to be something of a novice C programmer, I like to go
through my code a few times to see if I can optimize it further before the
compiler gets to it.  Second, it leaves enough bread crumbs behind that
when I look at it later on I can remember what I did and why.  That's nice
no matter how many lines you use to do the same thing.

Of course, to be more accurate in this particular case I should say I
*would* do it that way if I were clever enough to have squeezed it down
that far int he first place.  I doubt I would have figured out how to make
it *that* concise.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@162347 by Dipperstein, Michael

face picon face
{Quote hidden}

Though a one line while loop looks clean, and comments above it can make it so a
novice can understand the code.  I think something is being overlooked.  The
code may need to be debugged for any number of reasons.

When stepping through code at source level, a single step in the one line copy
takes you through the copy, two increments, and a compare.  That's a fair amount
of instructions and our bug could have occurred at any one of those phases.

while ((*s = *t) != '\0')
{
   s++;
   t++;
}

should generate the exact same code as the one line loop, but now I have smaller
resolution of a source level step.

If the generated code will be the same, I tend to go with the source that
performs minimizes the amount of instructions generated per source line of code.
It makes source level debugging with an ICE a little easier and it takes less
effort for me to parse a statement when I go back to it a few years later.

An other benefit is that there are many organizations that use source lines of
code as some kind of measurement.  If you find yourself working for one of those
organization, it will probably be in your benefit to inflate the source lines of
code you generate.

-Mike

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@170222 by Gerhard Fiedler

flavicon
face
At 14:35 10/26/2001 -0500, Dale Botkin wrote:
>So would you be as comfortable with one line of cryptic-looking code with
>five lines of comments explaining it, or five lines of perfectly clear
>code with one line of comments?  Or five and five?  Personally I tend
>toward the first:
>
>void strcpy (char *s, char *t) {
>      // This will copy from *t into *s, incrementing each
>      // pointer and looping until a null is encountered in
>      // *t.  Once we see a null, *s = *t evaluates to 0
>      // and the while loop ends.
>      while (*s++ = *t++);
>}

I would recommend writing code that needs as *little* comment as possible.
Comments are a maintenance nightmare. If you ever looked at code from other
people (or your own from a few years ago ;-) , you probably noticed how
many wrong comments are in there. Cut'n'paste without updating the comments
in the code, last minute bug-fixing with "fixing the comments later" (and
"later" never comes :) and all that kind of stuff.

So write your code as clearly as you (and your team members) need it, with
as little comment as possible. This includes the choice of identifiers -- a
variable or function name can be very helpful or quite misleading.

Look at this:

void strcpy (char *target, char *source) {
     while (1) {
          *target = *source;
          if( *source == '\0' )
               break;
          ++target; ++source;
     }
}

I would say it explains everything that you wrote in the comment in plain
C, without efficiency loss, without comments. No comments == no comments
that can be wrong...

ge

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@221734 by Bob Ammerman

picon face
----- Original Message -----
From: "Mark Skeels" <meskeelsspamspam_OUTEARTHLINK.NET>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, October 26, 2001 7:40 AM
Subject: [PIC]: or [EE]: C syntax question


{Quote hidden}

asignment
> operation and the increment operation into the while test portion?
>
> As a Pascal programmer, I was taught that anything that makes the program
> more readable is good. This does not seem to qualify on that count. What's
> more, it seems to muddle the entire while loop by mixing assignment and
> increment with the test portion.

In the good old days the compiler would likely be able to make better code
out of the second version than the first. Modern compilers should be able to
do about the same with either.

I agree that obscuring the code by jamming everything into the while
condition is bad, but sometimes it can make sense:

while ( 0 != (bytes_read = read()) )
{
   ...do something with the bytes...
}

The typical alternative would be:

bytes_read = read();
while (0 != bytes_read)
{
   ...do something with the bytes...
   bytes_read = read();
}
This of course has its own problems.


> Also, what is the logic behind understanding the actual test in the while
> loop? I can't understand from the syntax exactly what is being compared to
> '\0'. Is it *s? *t? If so, why?

It is the value assigned to *s. This is becauase the value of an assignment
statement is the value of the left hand argument.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@222917 by Bob Ammerman

picon face
> Simon,
>
> The "outcome" of the '=' operation is to place the contents of the
> expression on the right side of the '=' into the location given by
resolving
{Quote hidden}

Actually, this is not correct either. In the expression:

(x  = y) != '\0';

The comparison is to the value of the sub-expression (x = y).

This is defined to be the value of the left hand argument, not the right
hand one.

To see where this can make a difference:

char x;
int    y = 256;

(x = y) != 0

Since 'x' will be zero (when char is 8 bits), you will get a surprising
result.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\26@234733 by Dale Botkin

flavicon
face
> If the generated code will be the same, I tend to go with the source
> that performs minimizes the amount of instructions generated per
> source line of code. It makes source level debugging with an ICE a
> little easier and it takes less effort for me to parse a statement
> when I go back to it a few years later.

Excellent point.  You're right, the one-liner generates 30-odd lines of
assembly code, and it's easy yo lose the thread while trying to muddle
through it.  The least concise source gives you the best listing to step
thru the assembly code for debugging.

> An other benefit is that there are many organizations that use source
> lines of code as some kind of measurement.  If you find yourself
> working for one of those organization, it will probably be in your
> benefit to inflate the source lines of code you generate.

Never could understand that approach.  "Hey, we'll pay you more for
writing bloated messes of crap - we'll pay by the line no matter whether
it works or not!"  That's how we get operating systems that need a P-III
with 256MB of memory and 2G of disk to run.  Still, you've got a point,
some people do work for companies that judge quality by quantity.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\27@044846 by dr. Imre Bartfai

flavicon
face
Hi,

theoretically, the advantage of the 2nd version is, that the 1st one
implements a comparison against a constant (which could be an arbitrary
value), and the latter one checks whether the value of the pointed area
zero. Most architectures does the 2nd task more simple than the 1st
one. On the other hand, the compiler may be able to recognize that the
constant mentioned above is zero and *could* optimize the generated code
to achieve the tighter version would produce the 2nd code. But it is not
necessary the case in all situations.

Regards,
Imre

+-----------------------------------------------------------------------+
| The information transmitted is intended only for the person or entity |
| to which it is addressed and may contain confidential and/or          |
| privileged material.  Any review, retransmission, dissemination or    |
| other use of, or taking of any action in reliance upon, this          |
| information by persons or entities other than the intended recipient  |
| is prohibited. If you received this in error, please contact the      |
| sender and delete the material from any computer.                     |
+-----------------------------------------------------------------------+

On Fri, 26 Oct 2001, Dale Botkin wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\27@044914 by dr. Imre Bartfai

flavicon
face
Hi,

as an additional philosophical explaination about the fact which is rather
hardly to realize for programmers using another HLLs before (like me):

in C, even an assignment behaves itself from the compiler's point of view
as an expression. It has also a value which is actually the value of the
target after the assignment and this value can be moved, compared or even
serve as a parameter of a function call.

Regards,
Imre


+-----------------------------------------------------------------------+
| The information transmitted is intended only for the person or entity |
| to which it is addressed and may contain confidential and/or          |
| privileged material.  Any review, retransmission, dissemination or    |
| other use of, or taking of any action in reliance upon, this          |
| information by persons or entities other than the intended recipient  |
| is prohibited. If you received this in error, please contact the      |
| sender and delete the material from any computer.                     |
+-----------------------------------------------------------------------+

On Fri, 26 Oct 2001, Douglas Wood wrote:

{Quote hidden}

> {Original Message removed}

2001\10\27@084208 by Kevin Maciunas

flavicon
picon face
On Sat, 2001-10-27 at 00:10, Mark Skeels wrote:
{Quote hidden}

Since this has become a general thread along the lines of both style and
compiler intelligence, I'll contribute a couple of points (since I teach
students how to write compilers :-) ).

(1) C is a very low level programming language.  It is also an
*expression based* language (read: everything (almost) yields an
assignable value).  So the second form makes perfect sense: *s++ yields
a reference to a short (Note that C actually has no real type to
represent characters, ...).  A reference to a <blah> is a perfectly
acceptable thing to have as an L-Value for the "=" operator. And so
on...

(2) When you look inside the compiler, what you find is that the
syntactic constructs are turned into a tree like structure (an annotated
absract syntax tree [if you're one of my students :-) ]).  The trees
that would result from the two forms above are different, but not
substantially so.  When we come to "optimise" for code generation, we
can perform machine independant re-arrangements of that tree.  When you
do that, you'll discover that both of these [can] produce the same
tree.  So both forms will produce the same code.

In answering questions about style, I always duck for the following
shelter: always write code that is lucid.  Period.  You can assume that
the reader will be a programmer, but it should not matter too much that
they don't deeply understand the language.  The usual KISS principles
apply.  Never listen to people who say "nah...you can knock 4 lines off
if you just...".

In answering questions about "what is the best way to code for
efficiency in C": NEVER underestimate the compiler.  For short code
sequences, you can perhaps do better in assembler.  For longer code
sequences, write in a straight forward style - the compiler will have
the maximum number of optimisation tweaks set up for just that.  In the
land of the PIC, however, most compilers are not that smart -
unfortunately!

I've done a fair bit with PICs - only F84's and F877's however - and
have done it all in CCS C.  I've managed to re-use wads of code, and
have frequently looked at the code generated and seen places where it
could be a lot better.  Overall, however, it isn't bad at all.  [And
yes, I've had to work around compiler bugs].

Oops, excessively long post.  Apologies to all!

/Kevin
--
Kevin J. Maciunas              Net: spamBeGonekevinspamBeGonespamcs.adelaide.edu.au
Dept. of Computer Science      Ph : +61 8 8303 5845
University of Adelaide         Fax: +61 8 8303 4366
Adelaide 5005 SOUTH AUSTRALIA  Web: http://www.cs.adelaide.edu.au/~kevin

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\10\27@170502 by uter van ooijen & floortje hanneman

picon face
> As a Pascal programmer, I was taught that anything that makes the program
> more readable is good. This does not seem to qualify on that count.

This advice (make it more readable) is good, but it might not mean the same
thing to every programmer. A seasoned C programmer will instantly recognise
the compact version, so for him that is actually more readable than the
longer version, which is undoubtable easier to decode for a human - but the
seasoned C programmer does not decode at all - much like we do not spell
words when reading.

Personally I prefer the compact version for a different reason: I find code
easier to work on when I have less scrolling to do to view different parts,
and compactness helps to reduce scrolling (of course up to a certain -
probably person-dependent - level).

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.xs4all.nl/~wf/wouter/pic/jal

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\10\29@125133 by Mark Skeels

picon face
Gerhard, I really like what you said about comments. I can tell what your
code does at a glance; it was clear at first sight.

I can understand what you mean about maintenance. I worked on some large VB
projects which had been modified so many times that they _were_ a total
nightmare....the comments never seem to keep up with the code, anyway, and
the code suffers from "modificationitis..." too many patches and not enough
rewriting, with the only documentation being the code itself.

But with the pressures of delivery, these things always went by the wayside.
My situation now is much better. Keep at it until you get it right...:-)

Mark

> I would recommend writing code that needs as *little* comment as possible.
> Comments are a maintenance nightmare. If you ever looked at code from
other
> people (or your own from a few years ago ;-) , you probably noticed how
> many wrong comments are in there. Cut'n'paste without updating the
comments
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\29@134428 by D Lloyd

flavicon
face
part 1 3466 bytes content-type:text/plain; charset=us-ascii
Hi,

That function is very clear; decent code can always be self-documenting and
data abstraction (as long as it is not too abstract ;-) is always v.
useful.
It's no wonder, though, that a lot of "new" software people write code such
as

int a,b,c, i;

a = b*c;

and such like as I have seen code written like this used in Universities as
example code. I find that the only time that a block of comments should
really be required is to imply the full intent of why someone has done
something in a certain way like if they used algorithm a instead of
algorithm b because of some subtle effect it had on an interrupt or another
section of code; that always aids maintenance.

I heard that there was a Professor who said marked students down if their
code had comments at all; his argument was that if you wrote something in
French then you should know French/assume the reader knows French well
enough so that an English comment to explain what was going on is
unnecessary. Obviously he never had to write anything for the real world.

Regards,
Dan





(Embedded     Mark Skeels <meskeelsEraseMEspam.....EARTHLINK.NET>EraseMEspam.....MITVMA.MIT.EDU>> image moved   29/10/2001 16:14
to file:
pic19029.pcx)





Please respond to pic microcontroller discussion list
     <
EraseMEPICLISTspamMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>


To:   RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: or [EE]: C syntax question

Security Level:?         Internal


Gerhard, I really like what you said about comments. I can tell what your
code does at a glance; it was clear at first sight.

I can understand what you mean about maintenance. I worked on some large VB
projects which had been modified so many times that they _were_ a total
nightmare....the comments never seem to keep up with the code, anyway, and
the code suffers from "modificationitis..." too many patches and not enough
rewriting, with the only documentation being the code itself.

But with the pressures of delivery, these things always went by the
wayside.
My situation now is much better. Keep at it until you get it right...:-)

Mark

> I would recommend writing code that needs as *little* comment as
possible.
> Comments are a maintenance nightmare. If you ever looked at code from
other
> people (or your own from a few years ago ;-) , you probably noticed how
> many wrong comments are in there. Cut'n'paste without updating the
comments
> in the code, last minute bug-fixing with "fixing the comments later" (and
> "later" never comes :) and all that kind of stuff.
>
> So write your code as clearly as you (and your team members) need it,
with
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads






part 2 165 bytes content-type:application/octet-stream; (decode)

part 3 154 bytes
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\29@153447 by Gerhard Fiedler

flavicon
face
At 10:14 10/29/2001 -0600, Mark Skeels wrote:
>My situation now is much better. Keep at it until you get it right...:-)

You're in a lucky position then... try to keep it that way, it's a rare
luxury! :)

ge

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\29@154703 by Gerhard Fiedler

flavicon
face
At 18:35 10/29/2001 +0000, D Lloyd wrote:
>I find that the only time that a block of comments should
>really be required is to imply the full intent of why someone has done
>something in a certain way like if they used algorithm a instead of
>algorithm b because of some subtle effect it had on an interrupt or another
>section of code; that always aids maintenance.

The most important use for comments that I've found (besides the above
mentioned) are:
- header comments (files, classes, members, functions, variables) that
summarize a lot of code and typically are (or should be :)  found in header
files
- explaining odd workarounds for undocumented (or otherwise not immediately
obvious) behavior of connected software or hardware

>I heard that there was a Professor who said marked students down if their
>code had comments at all; his argument was that if you wrote something in
>French then you should know French/assume the reader knows French well
>enough so that an English comment to explain what was going on is
>unnecessary. Obviously he never had to write anything for the real world.

Depending on his assignments, he may have a point... :)

ge

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\29@155905 by uter van ooijen & floortje hanneman

picon face
I have a very personal reason why I favour code with little or no comments:
- the comments seldom explain something that is relevant, (still!) correct
and not immediately obvious
- comments often take up lines and my ability to understand code depends
heavily on the amount of code I can see on my monitor without scrolling.
For the same reason I prefer the compact coding style:
if( ... ) {
   ...
} else {
  ...
}

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\30@091815 by Lawrence Lile

flavicon
face
Ok, after lurking for a week I've gotta wiegh in.  Comments:

The first section of my code is a big comment section that elicidates the author of the code, title, List of I/O points for the target system, and a revision control system.  Each major revision is noted as to date, reason for revision, problems and issues still remaining, and author (always me.)  I save a copy of each revision under a different filename than the target, and often end up going back to an old revision level when some experiment does not work out.  
Each function (or macro in Assembler code) is commented with it's purpose, what variables should be passed to it, and any other notes about usage.  
After that exessive verbiage, I rarely write comments in the body of C code except to explain the obscure or to warn against a bug that was found.  " // Don't use a Long here, causes the dreaded Long Beard bug!"
In assembler, though, I write C pseudocode comments!  If I am making a loop in assembler, the comment may be ";;While (Lawrence == Cheapskate), Do (Tell him to get a life)"   or some such drivel.  
This professor who outlawed comments should be drawn and quartered. Comments are unnneccesary in the Ivory Tower, but out here where the rubber meets the road, they are lifelines.
-- Lawrence Lile

 {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...