TIP: Click on subject to list as thread! ANSI
echo: c_echo
to: Darin McBride
from: Bill Birrell
date: 2004-05-01 00:12:00
subject: Merits

> No, but I don't think that was ever my statement,
 > either.  The claim is that where there is no other
 > difference (i.e., you're using the increment purely
 > for the side effect of the increment), then use pre-
 > increment over post-increment.

    I have no preference there, but understand your point of view. As a
rule I try to use whichever one is more constructive in context. If there
is no other difference then clarity takes precedence.

 > For the more pedantic, I would go as far as to say
 > that you should almost never use the increment
 > operator when you want both the value and the
 > increment, such as *s++ or *++s.

    I thought we were already agreed on that.

 > Split it into two
 > statements (which is what for() is designed to do!).

    Which is where I differ. Again, I understand your point of view and for
commercial purposes it makes sense, but I no longer program commercially,
and therefore no longer have to maintain code. I will continue to use
elision (with care). However, if you have functions with 20 pages of code
in them, I agree you need all the stylistic rigidity you can impose on
yourself.

    You seem to have forgotten one of my foibles: no function in C should
actually take up more than 25 lines. If it does, it should be split up into
subroutines. C is designed for top down modularity in procedural programs.
Otherwise you can go nuts chasing bugs through pages of obscure and largely
irrelevant code.

    C++ is different. It is designed for oops. Debugging it is a different
game altogether, because C++ is a fourth generation language.

Best Wishes,
Bill.

---
* Origin: Escan BBS (2:25/200)
SEEN-BY: 633/267 270
@PATH: 25/200 108 252/110 250/501 140/1 106/2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.