× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Someone else suggested, "shoot the guy who wrote it". I tend to agree. . .
.

My main contribution to this discussion is to echo the person who said, "I
write for those who come after me". IMHO, this is what differentiates the
great programmer from the merely clever programmer. In my rookie days, I
wrote a lot  (well, maybe some ;-)) really clever code that even _I_
couldn't figure out six months later. After a while, I ended up re-writing
it, and I began to decide that the true test of really great code is that
it looks simple and obvious to someone who hasn't seen it before. If
you've tried it, you know this is a lot easier said than done.

I don't have an opinion on "+=" one way or another -- I agree that we all
like what we're used to, so those who grew up with C will probably like it
and those who didn't won't.  The discussion of UNIX/C constructs, though,
does remind me of the "GO TO" discussion we  had a while ago: some people
are saying "they make the code unreadable", and others saying "constructs
don't make code unreadable, bad programmers make code unreadable". Maybe
the culprit isn't "+=", but the desire to try to do too many things in one
line of code. . . .

JMHO

RPG400-L@midrange.com writes:
> >> Oh yeah, also performance.  Consider the statements:
>
> >>       Totals(FindItem('xyz')) += incr;
> >>       Totals(FindItem('xyz')) = Totals(FindItem('xyz')) + incr;
>
>>Isn't that more of a lack of optimization in the compiler and/or
>optimizing
>>tranlator than a performance issue Hans?
>
>
>In Hans defense:
>
>What if finditem returns the position of the first occurrence on the first
>call and the position of the next occurrence on each call their after.



Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.