when GOTO makes sense.

[Debashish Chakravarty]

K&R pg.66 describes two situations when using goto makes sense. Has
anyone here come across situations where using goto provided the most
elegant solution.

--
http://www.kashmiri-pandit.org/atrocities/index.html

[Dan Pop]

In <bq********@net news.proxy.luce nt.com> Ed Morton <mo************ ****@lucent.com > writes:

falls outside it or pushes the existing code outside of it. That's a
very common bug when modifying code that doesn't use braces on every
loop and "if". There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

That's the kind of mistake one is not very likely to repeat, after getting
burned once. So, there is no need to resort to braces in order to avoid
it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ed Morton]

Dan Pop wrote:

In <bq********@net news.proxy.luce nt.com> Ed Morton <mo************ ****@lucent.com > writes:

falls outside it or pushes the existing code outside of it. That's a
very common bug when modifying code that doesn't use braces on every
loop and "if". There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

That's the kind of mistake one is not very likely to repeat, after getting
burned once. So, there is no need to resort to braces in order to avoid
it.

I agree it's not a mistake that one person will make many times, but
it's a mistake that many people will make once, so it is still desirable
to use braces. Typing those couple of extra characters is no big deal
and is well worth the extra second or so of typing if it can avoid a
future bug being introduced. It also removes much of the need for using
"do { ... } while(0)" in compound-statement macros (though, to be
honest, I do that too since my macros are often used in other peoples code).

Ed.
Dan

[Alan Balmer]

On 4 Dec 2003 15:56:35 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <bq********@net news.proxy.luce nt.com> Ed Morton <mo************ ****@lucent.com > writes:

falls outside it or pushes the existing code outside of it. That's a
very common bug when modifying code that doesn't use braces on every
loop and "if". There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

That's the kind of mistake one is not very likely to repeat, after getting
burned once. So, there is no need to resort to braces in order to avoid
it.

Dan

The problem is that for real software products, maintained over a
number of years, it's not "one", but many.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net

[Dan Pop]

In <4d************ *************** *****@4ax.com> Alan Balmer <al******@att.n et> writes:

On 4 Dec 2003 15:56:35 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <bq********@net news.proxy.luce nt.com> Ed Morton <mo************ ****@lucent.com > writes:

falls outside it or pushes the existing code outside of it. That's a
very common bug when modifying code that doesn't use braces on every
loop and "if". There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

That's the kind of mistake one is not very likely to repeat, after getting
burned once. So, there is no need to resort to braces in order to avoid
it.

Dan

The problem is that for real software products, maintained over a
number of years, it's not "one", but many.

People who maintain software don't actually test the changes they make?

If I change a bit of code, it is because I want to alter its behaviour.
The next thing after doing it is testing it, to see if I got it right.
And if I didn't get it right, I find my bug(s) and fix the code.

Do I have some weird ideas about what software maintenance means?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ed Morton]

On 12/4/2003 12:42 PM, Dan Pop wrote:
<snip>

People who maintain software don't actually test the changes they make?

If I change a bit of code, it is because I want to alter its behaviour.
The next thing after doing it is testing it, to see if I got it right.
And if I didn't get it right, I find my bug(s) and fix the code.

Do I have some weird ideas about what software maintenance means?

Only if you think that any of the following is true:

a) There's no cost associated with finding a bug, fixing it, and retesting.
b) During developer-testing, every developer catches every bug they introduced.
c) All software can be tested thoroughly in a cheap development environment
(e.g. off the potentially expensive production hardware).

Ed.

[Christian Bau]

In article <bq********@net news.proxy.luce nt.com>,
Ed Morton <mo************ ****@lucent.com > wrote:

There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

Are you teaching courses "C for talentless beginners" ?

I cannot remember seeing that mistake being made in twenty years.

[Ed Morton]

Christian Bau wrote:

In article <bq********@net news.proxy.luce nt.com>,
Ed Morton <mo************ ****@lucent.com > wrote:

There's been so many times I've seen something like this:

if (x)
y();

get changed to:

if (x)
y();
z();

Are you teaching courses "C for talentless beginners" ?

No, I teach behavioral modeling, but I do inspect a lot of code written
by people with less experience.
I cannot remember seeing that mistake being made in twenty years.

Then you've been incredibly fortunate or don't get to inspect a lot of
code written by relative newcomers or have missed many mistakes.

Ed.

[James Dow Allen]

Ed Morton <mo************ ****@lucent.com > wrote in message news:<bq******* *@netnews.proxy .lucent.com>...

First: I did appreciate your words and your taking the time to rerun
the program. Sorry if I sounded irritable.

No. It was the loop termination condition that was the hardest to
understand. I don't mean I can't read the C, I just don't know what the
abstraction is for the C (i.e. what it "means").
The program does have a few comments, including one immediately
before the for statement you snipped: /* Loop to play tricks forward until the outcome is conclusive */
for (tnum = won = success = 0;
success ? ++won < need : won + ohsize >= need + tnum;
tnum++, P++, success = IS_CONT(pwin)) {
I assumed an understanding of whist and game search -- the loop
terminates when it is known either that contract will succeed or
won't succeed (and "success" will tell you which.)
I was wrong, it doesn't hang. It does just take a few minutes.
To change the subject, I was pretty sure the program would
run the 2nd input if it could run the 1st. Why? *Because it doesn't
rely on anything.* Some programs have code like
foogle_gark(Can onPrinter, DVI_Level17, REV14_3);
/* remember to ask Tony if we need to change this for
* Rev 14.4 (when line speed exceeds BAUDLIMIT_39) */
My program depended only on printf(), etc. which haven't changed
since the Pleistocene. And even the cheapest cell phone today
has enough memory to run it.

When someone demonstrates a working program almost as efficient and
more readable than mine, I'll "eat my hat."

Well, if you decomposed what you have into a few small functions (with
their own local variables ...)

Studying the program I believe you'll find that to be undoable.
You'll either need lots of global variables, or unwieldy state-
passing in both directions.
Until then, your words

are just idle pedantry.

You can dismiss my comments if you like, but I wasn't pedantic about
anything. I didn't say anything like "this code uses goto and therefore
is bad" I said "This code is hard to read, and here's some examples of why".

I apologize. My point was very badly phrased and, anyway, directed
more at another poster who over-generalized. I stand by my essential
point: My 200-line program is harder to read than a 500-line program,
but many programmers would construct a 2000-line solution if they could
do it all. Let's wait till the alternative is on display before
declaring it more readable.

James

[Dan Pop]

In <3F************ **@lucent.com> Ed Morton <mo************ ****@lucent.com > writes:

On 12/4/2003 12:42 PM, Dan Pop wrote:
<snip>

People who maintain software don't actually test the changes they make?

If I change a bit of code, it is because I want to alter its behaviour.
The next thing after doing it is testing it, to see if I got it right.
And if I didn't get it right, I find my bug(s) and fix the code.

Do I have some weird ideas about what software maintenance means?

Only if you think that any of the following is true:

a) There's no cost associated with finding a bug, fixing it, and retesting.
b) During developer-testing, every developer catches every bug they introduced.
c) All software can be tested thoroughly in a cheap development environment
(e.g. off the potentially expensive production hardware).

You're ignoring the punctual nature of the issue. There is no need to
perform a full retesting of the application, only the correctness of the
changes made needs to be tested, and this is, usually, far easier.

Anyone who changes the code and doesn't test his changes should be
kicked out of this profession.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ed Morton]

Dan Pop wrote:

In <3F************ **@lucent.com> Ed Morton <mo************ ****@lucent.com > writes:

On 12/4/2003 12:42 PM, Dan Pop wrote:
<snip> <snip>

Do I have some weird ideas about what software maintenance means?
Only if you think that any of the following is true:

a) There's no cost associated with finding a bug, fixing it, and retesting.
b) During developer-testing, every developer catches every bug they introduced.
c) All software can be tested thoroughly in a cheap development environment
(e.g. off the potentially expensive production hardware).

You're ignoring the punctual nature of the issue.

Not at all.

There is no need to perform a full retesting of the application, only the correctness of the
changes made needs to be tested, and this is, usually, far easier.
Of course rerunning one or 2 tests is easier/cheaper than retesting the
whole code. No-one suggested otherwise.
Anyone who changes the code and doesn't test his changes should be
kicked out of this profession.
s/should/will but that also has nothing whatsoever to do with anything I
said.

Ed.
Dan