Mailing List Archive

[strange programming]
The most confidence uninspiring piece of code I ever had the displeasure to
maintain contained something like this (allegedly C++, but mainly it's
intersection with C):

i = 0;
while( i < max_index ) {
/* some copying or update (not modifying i) goes here */
i = i + 1;
}

This was written by a *very* expensive consultant working for a large
multinational accountancy firm.

Can anybody suggest an alternative construct which more accurately expresses
the programmer's intentions? There may be more than one way to do it, but,
puhleeze!

Idiomatic is not quite the word.

--
Ben Caradoc-Davies <bmcd@es.co.nz>

Tom Christiansen <tchrist@mox.perl.com> wrote in comp.lang.perl.misc:

>I don't remember whether it also had these, but I have
>seen them elsewhere:
>
> #define forever() for(;;)
> #define unless(expr) if(!expr)

Let's just hope they had the sense to really

#define unless(expr) if(!(expr))

or else all bets are off.

Anno

Ben Caradoc-Davies wrote:
>
> [strange programming]
> The most confidence uninspiring piece of code I ever had the displeasure to
> maintain contained something like this (allegedly C++, but mainly it's
> intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
> This was written by a *very* expensive consultant working for a large
> multinational accountancy firm.
>
> Can anybody suggest an alternative construct which more accurately expresses
> the programmer's intentions? There may be more than one way to do it, but,
> puhleeze!
>
> Idiomatic is not quite the word.

Try idiotic!

> --
> Ben Caradoc-Davies <bmcd@es.co.nz>

--
Matthew O. Persico

You'll have to pry my Emacs from my cold dead oversized
control-pressing left pinky finger. -- Randal L. Schwartz

On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bmcd@es.co.nz> wrote:
>[strange programming]
>The most confidence uninspiring piece of code I ever had the displeasure to
>maintain contained something like this (allegedly C++, but mainly it's
>intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
>This was written by a *very* expensive consultant working for a large
>multinational accountancy firm.

So what's wrong with that? Granted, the for loop construct would have
been better for the task instead of while, and the expensive consultant should
have seen that. But what about the i = i + 1 increment? It smacks of BASIC, but
there is nothing wrong with it. It's not any less efficient than i++ or ++i.

Maybe the consultant is anally retentive about not using operators other than
assignment that have the side effect of modifying an object, and not using more
than one side effect in a full expression. That approach leads to uninsipiring
code, but nevertheless code that won't possibly have undefined behaviors due to
ambiguities.

In other words, with his ultra-conservative approach, the weenie is unlikely
to ever things like a[i] = i++.

I'm afraid you don't have a case, if the program otherwise fulfilled its
functional, performance and reliability requirements.

The guy programs for accounting firms. So it's a given that he can't possibly
be a great hacker who writes slick code. He does things that some of us
wouldn't touch with a ten foot pole. His high cost could have something to do
with his domain specialization, and with a high profit margin on the part of
the contracting company (assuming he's not freelance).

Kaz Kylheku wrote:
>
> On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bmcd@es.co.nz> wrote:
> >[strange programming]
> >The most confidence uninspiring piece of code I ever had the displeasure to
> >maintain contained something like this (allegedly C++, but mainly it's
> >intersection with C):
> >
> > i = 0;
> > while( i < max_index ) {
> > /* some copying or update (not modifying i) goes here */
> > i = i + 1;
> > }
> >
> >This was written by a *very* expensive consultant working for a large
> >multinational accountancy firm.
>
> So what's wrong with that?
[Nice defense elided.]

Those that think that code is bad have I suspect have never seen bad code.
Anyway, I bet many people missed the really bad part in that code, which is
the placement of the { <Wink>. Note the only approved location for curly
brackets:

i = 0;
while(i < max_index)
{
/* Blah blah. */
i = i + 1;
}

(I use Python whenever I can just to get away from these curly bracket wars.
<0.7 wink>)

Kaz Kylheku (kaz@ashi.FootPrints.net) wrote on MMCLXXV September MCMXCIII
in <URL:news:slrn7re808.77t.kaz@ashi.FootPrints.net>:
## On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bmcd@es.co.nz> wrote:
## >[strange programming]
## >The most confidence uninspiring piece of code I ever had the displeasure to
## >maintain contained something like this (allegedly C++, but mainly it's
## >intersection with C):
## >
## > i = 0;
## > while( i < max_index ) {
## > /* some copying or update (not modifying i) goes here */
## > i = i + 1;
## > }
## >
## >This was written by a *very* expensive consultant working for a large
## >multinational accountancy firm.
##
## So what's wrong with that? Granted, the for loop construct would have
## been better for the task instead of while, and the expensive consultant shoul
## have seen that. But what about the i = i + 1 increment? It smacks of BASIC, b
## there is nothing wrong with it. It's not any less efficient than i++ or ++i.


I would still argue we don't know enough about the program to say it's
wrong or bad style. The last line is easily modified to "i = i + 2", or
"i = i * 1.5", or "i = i + a", where a is depending on the rest of the
statements in the block. I would prefer using "i = i + 1" or "i += 1"
if I mean "I add a number to i, which happens to be 1 in this case" over
"i ++", which in my book means, "I am counting" or "it's the next one".
I don't think using 'for (i = 0; i < max_index; i = i + 1) {}' is going
to buy me anything over the while. Except that's less flexible. Thinking
about the next programmer? Gimme a break. A programmer that gets confused
when seeing a while that could be written as a for shouldn't touch the
code anyway.


It's the same with !i and i == 0. With !i, i is acting as a boolean, while
in "i == 0", I am comparing i to a specific value. That the value just
happens to be 0 doesn't warrent a change in syntax.


Abigail
--
$" = "/"; split $, => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%{"@_"} = %_ = (Just => another => Perl => Hacker); &{%{%_}};


-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----

In article <slrn7re808.77t.kaz@ashi.FootPrints.net>,
Kaz Kylheku <kaz@ashi.FootPrints.net> wrote:
>On 15 Aug 1999 03:14:48 GMT, Ben Caradoc-Davies <bmcd@es.co.nz> wrote:
>>
>>The most confidence uninspiring piece of code I ever had the displeasure to
>>maintain contained something like this (allegedly C++, but mainly it's
>>intersection with C):
>>
>> i = 0;
>> while( i < max_index ) {
>> /* some copying or update (not modifying i) goes here */
>> i = i + 1;
>> }
>>
>>This was written by a *very* expensive consultant working for a large
>>multinational accountancy firm.
>
>So what's wrong with that? Granted, the for loop construct would have
>been better for the task instead of while, and the expensive consultant
>should have seen that. But what about the i = i + 1 increment? It
>smacks of BASIC, but there is nothing wrong with it. It's not any less
>efficient than i++ or ++i.

Not only that, but perhaps that was the third or fourth draft of the
code, and a while loop was more appropriate for the original draft.
It's often the case that even when I know there's a more "appropriate"
structure for code that I'm modifying, I leave the old code intact as
long as there's nothing actually *wrong* with it -- fewer changes
equates to fewer bugs (not always, but in general).
--
--- Aahz (@netcom.com)

Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6 (if you want to know, do some research)

On Sun, 15 Aug 1999 20:15:44 GMT, Kaz Kylheku <kaz@ashi.FootPrints.net> wrote:
[reinventing "for"]
>So what's wrong with that? Granted, the for loop construct would have
>been better for the task instead of while, and the expensive consultant should
>have seen that. But what about the i = i + 1 increment? It smacks of BASIC, but
>there is nothing wrong with it. It's not any less efficient than i++ or ++i.

The question is not one of efficiency but one of expressing the intent of the
programmer. Seeing this written as a while loop made me double take ...
where's the trick? What is going on here?

There is nothing wrong with i = i + 1 (especially for us Pythonistas :-), but
taken together with the loop it suggests an unfamiliarity with the accepted
idioms of the language.

>Maybe the consultant is anally retentive about not using operators other than
>assignment that have the side effect of modifying an object, and not using more
>than one side effect in a full expression. That approach leads to uninsipiring
>code, but nevertheless code that won't possibly have undefined behaviors due to
>ambiguities.
>In other words, with his ultra-conservative approach, the weenie is unlikely
>to ever things like a[i] = i++.

I wish this were the case, but given the rest of the code, I doubt it. You are
however, most charitable and tolerant :-)

>I'm afraid you don't have a case, if the program otherwise fulfilled its
>functional, performance and reliability requirements.

[Warning: may contain traces of rants]

The program did have some annoying bugs, and it was in the hunt for these that
the, er, unusual code was found. However, the program did mostly fulfil its
functional, performance, and reliability requirements, as they existed at the
time. And here's the rub:

A program must fulfil more than just those requirements, but also that of
maintainability. I'm sure I don't have to remind anyone here that a piece of
source code is a living document, and should be amenable to change (which is
why I was working on it in the first place).

The real problem I had with the project in question was that (except for some
crucial headers), the entire source code was almost uncommented except for a
copyright notice at the top of each source file. Understanding the code was an
exercise in reverse-engineering the intent of the programmer. I've seen this in
scientific software (such as the 49000 LOC of uncommented Fortran 77 written by
an engineer with english as a second language, with no use of procedures and
the entire flow-control managed by circuitous GOTOs and global variables), but
in a business environment it is unforgiveable.

When I left, I passed the [C++] project on to my successor, who was quite a
greenhorn. Meanwhile, the original author had fled the country. Now the current
project manager ("ANSI C? No I haven't heard of that company.") is leaving too.
The only record of what the code is meant to do is some outdated manuals and
the source code. This is mission-critical business software.

>The guy programs for accounting firms. So it's a given that he can't possibly
>be a great hacker who writes slick code. He does things that some of us
>wouldn't touch with a ten foot pole. His high cost could have something to do
>with his domain specialization, and with a high profit margin on the part of
>the contracting company (assuming he's not freelance).

I'm sure he would have only seen a tiny slice of what the multinational charged
for his time. However, I think his price was due more to the gullibility of the
client and wandering project control than the domain. This is a bog-standard
database front-end!

Phew!

--
Ben Caradoc-Davies <bmcd@es.co.nz>

On 15 Aug 1999 21:45:57 GMT, Aahz Maruch <aahz@netcom.com> wrote:
>Not only that, but perhaps that was the third or fourth draft of the
>code, and a while loop was more appropriate for the original draft.
>It's often the case that even when I know there's a more "appropriate"
>structure for code that I'm modifying, I leave the old code intact as
>long as there's nothing actually *wrong* with it -- fewer changes
>equates to fewer bugs (not always, but in general).

Sure, if it ain't broke ...

Unfortunately, in this case, the original specifications appear to have been
reduced, and there are huge chunks of partly implemented and even obsolete
code, including a large source source file which should have been entirely
deleted as it's functionality had been absorbed into another. This was only
deducible by examiing the linker options.

If there was any evidence of a drafting process, it wasn't obvious.

But yes, there may well have been something more complicated in the loop. For
example, if he was messing with "i" in the loop, a while loop would have been
a good way to draw another programmer's attention to the fact that something
fishy was going on, if he was so averse to comments.

--
Ben Caradoc-Davies <bmcd@es.co.nz>

On 15 Aug 1999 22:18:59 GMT, Ben Caradoc-Davies <bmcd@es.co.nz> wrote:
>There is nothing wrong with i = i + 1 (especially for us Pythonistas :-), but
>taken together with the loop it suggests an unfamiliarity with the accepted
>idioms of the language.

It does suggest that. But it could also be some religous thing. As in ``I won't
use this evil ++ thing because KRUDBAL didn't have it, and KRUDBAL is the
finest programming language there ever was. So if it's not in KRUDBAL, you
don't need it.''

:)

Ben Caradoc-Davies wrote:
>
> [strange programming]
> The most confidence uninspiring piece of code I ever had the displeasure to
> maintain contained something like this (allegedly C++, but mainly it's
> intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
> This was written by a *very* expensive consultant working for a large
> multinational accountancy firm.
>
> Can anybody suggest an alternative construct which more accurately expresses
> the programmer's intentions? There may be more than one way to do it, but,
> puhleeze!
>

Yes I can:

i = 0;
label_1:;
/* some use of i */
i = i + 1;
if (i==max_index) goto label_2;
goto label_1;
label_2:;

<wink>

--
Patrick W. Bogaart
Department of Geomorphology and Quaternary Geology
Faculty of Earth Sciences, Vrije Universiteit Amsterdam
bogw@geo.vu.nl http://www.geo.vu.nl/users/bogw

Patrick Bogaart <bogw@geo.vu.nl> wrote:
> > i = 0;
> > while( i < max_index ) {
> > /* some copying or update (not modifying i) goes here */
> > i = i + 1;
> > }

>
> i = 0;
> label_1:;
> /* some use of i */
> i = i + 1;
> if (i==max_index) goto label_2;
> goto label_1;
> label_2:;
>
> <wink>

To get the correct behavior for values of max_index less than 0, you need
to change the test from "i == max_index" to "i >= max_index", and you also
need to move the test to directly after label_1. Other than that, it
looks like perfectly reasonable ratfor-type output (except that the labels
should start at 23001).

--
Roy Smith <roy@popmail.med.nyu.edu>
New York University School of Medicine

Patrick Bogaart <bogw@geo.vu.nl> wrote in article
<37BAE44B.E66250BD@geo.vu.nl>...
> Yes I can:
>
> i = 0;
> label_1:;
> /* some use of i */
> i = i + 1;
> if (i==max_index) goto label_2;
> goto label_1;
> label_2:;
>
> <wink>

I found this last week:

if ( something )
{
}
else
{
A process that sets the success variable
if (! success )
goto Error;
}
Error:

Note that there was nothing between the goto and and the label
except the end of the else clause. -Wm

William> if ( something )
William> {
William> }
William> else
William> {
William> A process that sets the success variable
William> if (! success )
William> goto Error;
William> }
William> Error:

William> Note that there was nothing between the goto and and the label
William> except the end of the else clause. -Wm

Planning ahead, no doubt. ;-)

Skip Montanaro | http://www.mojam.com/
skip@mojam.com | http://www.musi-cal.com/~skip/
847-971-7098

In article <37b62939@cs.colorado.edu>,
Tom Christiansen <tchrist@mox.perl.com> wrote:
>Gosh yes. I think it was the rogue source that had something like:
>
> #define until(expr) while(!expr)
> #define otherwise break; default:
>
>I don't remember whether it also had these, but I have
>seen them elsewhere:
>
> #define forever() for(;;)
> #define unless(expr) if(!expr)

I've seen

#define ARBEGIN {
#define AREND }

in Clipper (a somewhat C-ish language in this regard) code.

Eh?

Mark W. Schumann writes ..
>In article <37b62939@cs.colorado.edu>,
>Tom Christiansen <tchrist@mox.perl.com> wrote:
>>Gosh yes. I think it was the rogue source that had something like:
>>
>> #define until(expr) while(!expr)
>> #define otherwise break; default:
>>
>>I don't remember whether it also had these, but I have
>>seen them elsewhere:
>>
>> #define forever() for(;;)
>> #define unless(expr) if(!expr)
>
>I've seen
>
>#define ARBEGIN {
>#define AREND }

in his section on Privacy in "Advanced Perl Programming" Sriram
Srinivasan mentions (as a counterexample to syntactically enforced
privacy) seeing the following in some C++ code just before a header file
was included

#define private public

there must be something wrong with me .. because I'd never thought of
that

--
jason - elephant@squirrelgroup.com -

Ben Caradoc-Davies wrote:
>
> [strange programming]
> The most confidence uninspiring piece of code I ever had the displeasure to
> maintain contained something like this (allegedly C++, but mainly it's
> intersection with C):
>
> i = 0;
> while( i < max_index ) {
> /* some copying or update (not modifying i) goes here */
> i = i + 1;
> }
>
> This was written by a *very* expensive consultant working for a large
> multinational accountancy firm.
>
I think I can explain this. The original code was written to compile
not under C++, but under a little known and short-lived language known
as "C=C+1". It was to C++ as Python is to Perl.

Mark W. Schumann (catfood@apk.net) wrote:
: I've seen
:
: #define ARBEGIN {
: #define AREND }
:
: in Clipper (a somewhat C-ish language in this regard) code.
:
: Eh?

In Clipper, curly braces are used as anonymous array constructors, so
those mnemonics are presumably short for "array begin" and "array end."

In article <7phs0o$17q@dfw-ixnews16.ix.netcom.com>,
Eric Bohlman <ebohlman@netcom.com> wrote:
>Mark W. Schumann (catfood@apk.net) wrote:
>: I've seen
>:
>: #define ARBEGIN {
>: #define AREND }
>:
>: in Clipper (a somewhat C-ish language in this regard) code.
>:
>: Eh?
>
>In Clipper, curly braces are used as anonymous array constructors, so
>those mnemonics are presumably short for "array begin" and "array end."

Yes, I know.

What I don't know is how the heck this guy thought that made the code
more clear!