Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149567 > unrolled thread
| Started by | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| First post | 2020-01-31 23:46 +0300 |
| Last post | 2020-02-29 03:30 -0800 |
| Articles | 20 on this page of 137 — 34 participants |
Back to article view | Back to comp.lang.c
Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:46 +0300
Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:54 +0300
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-01-31 19:13 -0600
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 07:52 -0800
Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 00:06 +0300
Re: Coding style for small if statements mathog <dmathog@gmail.com> - 2020-02-28 10:20 -0800
Re: Coding style for small if statements Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-31 16:28 -0500
Re: Coding style for small if statements donalhambra@gmail.com - 2020-02-01 04:55 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:16 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-02 11:03 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-03 02:20 +0000
Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-03 05:17 +0100
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 04:07 -0800
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-03 12:59 -0800
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 20:54 -0800
Re: Coding style for small if statements nobody@example.org (Scott) - 2020-02-01 16:44 +0000
Re: Coding style for small if statements already5chosen@yahoo.com - 2020-02-02 04:40 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-02 15:47 +0100
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 23:56 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:34 -0800
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:17 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:28 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 21:52 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:07 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:22 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:25 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 02:35 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 20:20 -0800
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:04 -0500
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:05 -0500
Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-05 12:50 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:36 +0000
Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-06 15:01 -0800
Re: Coding style for small if statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-06 15:43 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:02 +0100
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:24 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:03 +0000
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 23:59 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 00:16 +0000
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-08 02:26 +0000
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 17:07 -0600
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 23:17 +0000
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 18:32 -0600
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-09 09:32 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 07:10 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 01:26 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:30 +0100
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-07 05:36 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:36 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-08 17:20 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 02:07 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 13:01 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 13:26 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:53 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 17:03 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:35 +0000
Re: Coding style for small if statements Manfred <noname@add.invalid> - 2020-02-09 18:07 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:17 +0000
Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-11 07:19 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Öö Tiib <ootiib@hot.ee> - 2020-02-10 23:40 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-12 12:24 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Bart <bc@freeuk.com> - 2020-02-11 11:30 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-02-11 09:41 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-12 08:12 -0500
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:18 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 00:01 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-22 05:22 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:57 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:28 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-12 07:56 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) chad <cdalten@gmail.com> - 2020-02-12 08:57 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:31 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-14 14:10 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-15 03:06 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 19:45 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:50 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 22:51 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:39 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:55 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 11:07 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 12:48 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 13:13 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 15:15 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 15:46 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:18 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:12 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 14:51 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:19 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 21:00 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:29 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-09 17:14 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:15 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:43 -0500
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:25 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 01:19 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:43 -0800
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-16 14:01 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:34 -0800
Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-07 15:25 +0100
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-07 07:22 -0800
Re: Coding style for small if statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-02-14 15:21 +0300
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-14 13:35 +0000
Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-14 14:43 +0100
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-15 12:08 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 10:10 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-20 19:58 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:55 -0800
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:26 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-07 17:47 -0800
Re: Coding style for small if statements jadill33@gmail.com - 2020-02-10 07:09 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:30 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 16:14 +0100
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:40 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 17:48 +0100
Re: Coding style for small if statements Robert Wessel <robertwessel2@yahoo.com> - 2020-02-16 17:14 -0600
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-30 00:27 -0700
Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-02-16 18:39 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 20:37 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-17 09:09 +0100
Re: Coding style for small if statements Öö Tiib <ootiib@hot.ee> - 2020-02-17 05:32 -0800
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-17 18:07 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-17 23:48 +0000
Re: Coding style for small if statements Richard Damon <Richard@Damon-Family.org> - 2020-02-17 20:40 -0500
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-23 10:14 -0800
Re: Coding style for small if statements Ike Naar <ike@iceland.freeshell.org> - 2020-02-23 20:16 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-29 18:56 -0700
Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-30 06:07 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-30 06:45 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-03-30 10:50 +0200
Re: Coding style for small if statements gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-30 13:04 +0000
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-30 06:17 -0700
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 14:09 -0700
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 02:09 -0800
Re: Coding style for small if statements Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2020-02-10 01:47 +0000
Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-12 17:54 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 07:18 -0800
Re: Coding style for small if statements fir <profesor.fir@gmail.com> - 2020-02-29 03:30 -0800
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-02-16 16:17 +0000 |
| Message-ID | <slrnr4iqor.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #150046 |
On Sun, 2020-02-16, Tim Rentsch wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Fri, 2020-01-31, Anton Shepelev wrote:
>>
>>> Hello, all
>>>
>>> What do you think about the formatting and readability of
>>> the following code of mine from a display-setup function for
>>> the DOSBox emulator:
>>>
>>> if( dblh != dblw )
>>> if( dblh ) gfx_flags |= GFX_DBL_H; else
>>> gfx_flags |= GFX_DBL_W;
>>
>> ...
>>
>>> What are your opinions?
>>
>> My opinion is simple: I like and use a short, simple, one-line if:
>>
>> if (dblh) gfx_flags |= GFX_DBL_H;
>
> I am curious. Would your criteria for shortness and simpleness
> admit the whole ball of wax here as a single one-line statement:
>
> if( dblh != dblw ) gfx_flags |= dblx ? GFX_DBL_H : GFX_DBL_H;
^ ^
You mean:
if( dblh != dblw ) gfx_flags |= dblh ? GFX_DBL_H : GFX_DBL_W;
which suggests that the names are the biggest problem in that
code. (Someone mentioned the names upthread, too.)
> My own criteria for admitting a one-line 'if' include the question
> "Does this make sense being read as a single line?", which probably
> gets a Yes answer in this case. (The "probably" arises because
> there may be other not-yet-known context that would bear on the
> question.)
"Maybe, depending on context" here, so almost the same answer. I'm not
a big fan of conditionals- within-conditionals, and would stop to ask
myself "is there an obvious way to simplify this"?
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-22 08:28 -0800 |
| Message-ID | <86eeumd1s2.fsf@linuxsc.com> |
| In reply to | #150055 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sun, 2020-02-16, Tim Rentsch wrote: > >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> >>> On Fri, 2020-01-31, Anton Shepelev wrote: >>> >>>> Hello, all >>>> >>>> What do you think about the formatting and readability of >>>> the following code of mine from a display-setup function for >>>> the DOSBox emulator: >>>> >>>> if( dblh != dblw ) >>>> if( dblh ) gfx_flags |= GFX_DBL_H; else >>>> gfx_flags |= GFX_DBL_W; >>> >>> ... >>> >>>> What are your opinions? >>> >>> My opinion is simple: I like and use a short, simple, one-line if: >>> >>> if (dblh) gfx_flags |= GFX_DBL_H; >> >> I am curious. Would your criteria for shortness and simpleness >> admit the whole ball of wax here as a single one-line statement: >> >> if( dblh != dblw ) gfx_flags |= dblx ? GFX_DBL_H : GFX_DBL_H; > > ^ ^ > You mean: > > if( dblh != dblw ) gfx_flags |= dblh ? GFX_DBL_H : GFX_DBL_W; Yes I did. Fortunately you have trained your neural network to recognize and correct these minor typographical errors. > which suggests that the names are the biggest problem in that > code. (Someone mentioned the names upthread, too.) > >> My own criteria for admitting a one-line 'if' include the question >> "Does this make sense being read as a single line?", which probably >> gets a Yes answer in this case. (The "probably" arises because >> there may be other not-yet-known context that would bear on the >> question.) > > "Maybe, depending on context" here, so almost the same answer. I'm not > a big fan of conditionals- within-conditionals, and would stop to ask > myself "is there an obvious way to simplify this"? I'm not a big fan of conditionals, and so even less of a fan of conditionals-within-conditionals. However I think for me there is also something more fundamental. Using if() or if()/else is about expressing differences. Using ?: is about emphasizing similarities. Here the common elements of the (original two) assignments deserve to be highlighted, and ?: does that very effectively. That the result fits nicely into a single-line if() statement is just icing on the cake. Still it's nice to hear we arrive at (at least almost) the same destination.
[toc] | [prev] | [next] | [standalone]
| From | skybuck2000@hotmail.com |
|---|---|
| Date | 2020-02-03 21:52 -0800 |
| Message-ID | <f113796e-bd27-48d0-9df1-e2011f73f5b5@googlegroups.com> |
| In reply to | #149567 |
Pretty shitty indeed, easier to mis-read it.
When I first saw it I thought it was case 2.
But now that I look at it again it is probably case 1.
The inner if statement appears to be terminated by ;
These terminators are very annoying, this is where python is a blessing.
But I am a Delphi programmer at hard, and kinda hate these ; terminator, leads to huge ammounts of time wasted forgetting these things.
Basically you are 1 character away from a very serious and hard to find bug ;)
So don't do it.
This is why I usually use begin end statements in Delphi, makes the code more robust, easier to read and expandable.
It does cause some whitespace/extra vertical lines to be added, which makes the entire code harder to read vertically, can't see what you doing cause of all the vertical lines, I am kinda used to it.
But again this is where python is probably better for most code situations.
This situation I don't know and would be interesting to ask pythong developers.
From what I can remember this would look like
if A < B:
if C:
E
else:
D
So the forcefull identation of pythong would have made it clear.
Unfortunately you were left "free" in C to fuck up the identation and now the reader pays for it.
Believing the else statement belongs to the inner if statement.
While in reality it is probably the outer statement.
This is a nice example of a identation fuck up (by you :))
Bye for now,
Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | skybuck2000@hotmail.com |
|---|---|
| Date | 2020-02-03 22:07 -0800 |
| Message-ID | <77d161fe-8957-4132-a88f-ba87083d4635@googlegroups.com> |
| In reply to | #149709 |
Interesting I decided to look at other people's reactions only after I wrote mine, just to stay independant and then apperently my initial hunch was the correct one but I don't quite agree with this and therefore I find this funny and going to investigate how this works in Delphi vs C/CPP:
I converted your code into the easier example:
int _tmain(int argc, _TCHAR* argv[])
{
int a, b, c, d, e;
a = 10;
b = 20;
c = 30;
d = 40;
e = 50;
if( a != b )
if( a ) c = d; else
c = e;
printf("%d /n", c );
return 0;
}
if a then c = 40
if not a then c = 50
if a=b then c = 30
Hmmm so far the result in Delphi is the same:
procedure Main1;
var
a, b, c, d, e : integer;
begin;
a := 10;
b := 20;
c := 30;
d := 40;
e := 50;
if( a <> b ) then
if ( a <> 0 ) then c := d else
c := e;
writeln( c );
end;
begin
Main1;
readln;
end.
Only funny thing is the ; before the else must be removed in Delphi and in C it must be placed.
Kinda weird.
At least it's not leading to different results =D
There is also no way to fuck this up, delphi will force begin/end statements if else is supposed to be outer if...
Same basically in C will also force { }
Bye for now,
Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | skybuck2000@hotmail.com |
|---|---|
| Date | 2020-02-03 22:22 -0800 |
| Message-ID | <3903a957-7ebf-4428-b518-b54195af9a2a@googlegroups.com> |
| In reply to | #149710 |
I guess what I am trying to say and what the moral of the story is:
The ; terminator could be interpreted as pascal/delphi programmers as a terminated if statement and thus perhaps the ; terminator forces the else to belong to the outer if statement.
However this reasoning and any reasoning about the terminator being there or not would be wrong.
Both languages force begin/end {} statements to be used if it is to be part of the outer if statement.
However this begs the question: Why is C and Delphi vice versa ?!
This adds confusion at best ! ;)
And thus this code isn't really language-port friendly ! =D
For now I will consider this something sloppy/inconsistent in the programming languages.
I think I like C's method better. I don't like else statements without terminators in front of them if it's single line...
if { } else { }; ?
if then begin end else begin end; ?
Not sure if this would be allowed in C but it is allowed in Delphi.
Will test it out just in case:
Yup compiles in Delphi:
if a=b then begin c:=d end else begin c:=e end;
Funny enough Visual Studio 2010 fails:
if (a==b) { c=d } else { c=e };
Fails again:
if (a==b) { c=d } ; else { c=e };
Fails again:
if (a==b) ; { c=d } else { c=e };
LOL. This is why I don't code in C and VS it's total junk.
Not mentioning the ".net framework bullshit" when re-opening the project.
Fail.
Also installing community edition without CNG service running
Fail.
Way too much fail for my taste.
I wouldn't even know or care at this point how to get the above working, maybe it's not even allowed.
Well have fun reading the C specification if it's not allowed, or if it's allowed and how to fix it.
I got better things to do for now, so see ya later !
But I will come back and read any answers or fixes to the FAIL C above.
Doesn't mean that I necessary like else statement above...
I don't like else statements without begin/end statements... usually...
Sometimes I like it a little bit... but I know the dangerous and this is one of em.
Also formatters/code beautifiers might get confused then again I am not even sure about that ! ;)
It's hard to tell if it's a source formatter beautifier bug or if identation is supposed to be like that when there are many of these if else statements, thus using begin end should be easier to beautify and eventually parse.
Bye for now,
Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | skybuck2000@hotmail.com |
|---|---|
| Date | 2020-02-03 22:25 -0800 |
| Message-ID | <4f22de16-3646-4be2-bc4e-1f7576aa4838@googlegroups.com> |
| In reply to | #149711 |
Ok finally succeeded:
if (a==b) { c=d; } else { c=e; };
And this also works:
if (a==b) { c=d; } else { c=e; }
That is a lot of time wasted trying to figure out where this ; terminator belongs ! ;)
Bye for now,
Skybuck.
P.S.: I'd be interested in a Delphi-Python hybrid to get rid of these shitty ; terminators ! ;)
Now you know why ! ;) =D
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-05 02:35 +0000 |
| Message-ID | <87mu9xpxqw.fsf@bsb.me.uk> |
| In reply to | #149711 |
skybuck2000@hotmail.com writes:
<cut>
> Funny enough Visual Studio 2010 fails:
>
> if (a==b) { c=d } else { c=e };
>
> Fails again:
>
> if (a==b) { c=d } ; else { c=e };
>
> Fails again:
>
> if (a==b) ; { c=d } else { c=e };
>
> LOL. This is why I don't code in C and VS it's total junk.
VS is correct here -- you just did not get the right syntax. In C, the
semicolon is a statement terminator. Without a ; the assignments in
your examples are just expressions. Add a ; and they become expression
statements:
if (a == b) { c = d; } else { c = e; }
This is valid C.
A semicolon on its own is a value expression statement (one that does
nothing) so can add them in many places like this:
if (a == b) { c = d;; } else { c = e;;;; };
You could even replace either or both compound statements with empty
statements:
if (a == b) ; else { c = e; }
if (a == b) { c = d; } else ;
if (a == b) ; else ;
This last one does nothing in both cases (when a == b and when a != b).
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-02-04 20:20 -0800 |
| Message-ID | <a59b0f75-6feb-46b5-b22b-2980ba1e54c6@googlegroups.com> |
| In reply to | #149747 |
On Tuesday, February 4, 2020 at 9:36:06 PM UTC-5, Ben Bacarisse wrote: ... > A semicolon on its own is a value expression statement (one that does > nothing) so can add them in many places like this: "value" => "valid" The C standard refer to such expression statements as "null statements".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-02-05 01:04 -0500 |
| Message-ID | <r1dlt8$igl$1@dont-email.me> |
| In reply to | #149748 |
On 2/5/20 12:37 AM, Stefan Ram wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On Tuesday, February 4, 2020 at 9:36:06 PM UTC-5, Ben Bacarisse wrote:
>>> A semicolon on its own is a value expression statement (one that does
^^^^^^^^^^^^^^^^^^^^
...
> And also, syntactically, as an »expression-statement«, via 6.8.3p1:
>
> expression-statement:
> expression_opt ;
Keith already said that.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-02-05 01:05 -0500 |
| Message-ID | <r1dlvo$igl$2@dont-email.me> |
| In reply to | #149748 |
On 2/5/20 12:37 AM, Stefan Ram wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On Tuesday, February 4, 2020 at 9:36:06 PM UTC-5, Ben Bacarisse wrote:
>>> A semicolon on its own is a value expression statement (one that does
^^^^^^^^^^^^^^^^^^^^'
...
> And also, syntactically, as an »expression-statement«, via 6.8.3p1:
>
> expression-statement:
> expression_opt ;
Ben already said that.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2020-02-05 12:50 -0800 |
| Message-ID | <65de5d07-838a-4a5f-bd70-b8a263fc61d6@googlegroups.com> |
| In reply to | #149567 |
On Friday, January 31, 2020 at 2:46:22 PM UTC-6, Anton Shepelev wrote:
> Hello, all
>
> What do you think about the formatting and readability of
> the following code of mine from a display-setup function for
> the DOSBox emulator:
>
> if( dblh != dblw )
> if( dblh ) gfx_flags |= GFX_DBL_H; else
> gfx_flags |= GFX_DBL_W;
>
Gah. That merits a paddlin'.
My personal rules:
1. Only omit braces for the innermost if (when applicable), and only if it does not have
an associated else;
2. Braces and else go on their own lines;
3. Braces line up with the if and else;
To wit:
if ( dblh != dblw )
{
if ( dblh )
{
gfx_flags |= GFX_DBL_H;
}
else
{
gfx_flags |= GFX_DBL_W;
}
}
Unambiguous. It's clear which if the else belongs to, it's clear which branch is taken
based on the conditions, etc. You won't introduce a bug if you decide to add a logging
statement to either branch. It sacrifices some vertical space (and a little visual clutter),
but nobody's going to come tracking you down later to ask what the hell you meant.
Always write code assuming the person maintaining it is a violent psychopath who knows
where you live.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-05 23:36 +0000 |
| Message-ID | <87imkkobdm.fsf@bsb.me.uk> |
| In reply to | #149774 |
John Bode <jfbode1029@gmail.com> writes:
> On Friday, January 31, 2020 at 2:46:22 PM UTC-6, Anton Shepelev wrote:
>> Hello, all
>>
>> What do you think about the formatting and readability of
>> the following code of mine from a display-setup function for
>> the DOSBox emulator:
>>
>> if( dblh != dblw )
>> if( dblh ) gfx_flags |= GFX_DBL_H; else
>> gfx_flags |= GFX_DBL_W;
>>
>
> Gah. That merits a paddlin'.
>
> My personal rules:
>
> 1. Only omit braces for the innermost if (when applicable), and only if it does not have
> an associated else;
> 2. Braces and else go on their own lines;
> 3. Braces line up with the if and else;
>
> To wit:
>
> if ( dblh != dblw )
> {
> if ( dblh )
> {
> gfx_flags |= GFX_DBL_H;
> }
> else
> {
> gfx_flags |= GFX_DBL_W;
> }
> }
>
> Unambiguous.
So was the original!
> It's clear which if the else belongs to, it's clear which branch is taken
> based on the conditions, etc.
How could it not be clear which "if" the "else" is part of? Now I can
imagine some people who might not know (which is not quite the same
thing), but I really don't want such a person maintaining /any/ code.
You hear a lot about the crisis in software (or you used to -- maybe
it's fixed now!). There's no hope, though, if software is being altered
by people who don't understand the original code as posted.
> You won't introduce a bug if you decide to add a logging
> statement to either branch.
That's not really what you mean. You mean it's easier to do so, or at
least less error prone in the face of people who just type code without
knowing what the language. (You can only add a statement to either
branch if you add {}s.)
> It sacrifices some vertical space (and a little visual clutter), but
> nobody's going to come tracking you down later to ask what the hell
> you meant.
It would be simpler to track down someone who knows C's syntax first.
> Always write code assuming the person maintaining it is a violent
> psychopath who knows where you live.
You missed off "and who agrees with you"! If they disagree with you
(like I do) you would not be safe (were I a violent psychopath) with all
the {}s in the world.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2020-02-06 15:01 -0800 |
| Message-ID | <726b2209-ca7e-40fe-b429-fbc062f5b6bd@googlegroups.com> |
| In reply to | #149780 |
On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
> > On Friday, January 31, 2020 at 2:46:22 PM UTC-6, Anton Shepelev wrote:
> >> Hello, all
> >>
> >> What do you think about the formatting and readability of
> >> the following code of mine from a display-setup function for
> >> the DOSBox emulator:
> >>
> >> if( dblh != dblw )
> >> if( dblh ) gfx_flags |= GFX_DBL_H; else
> >> gfx_flags |= GFX_DBL_W;
> >>
> >
> > Gah. That merits a paddlin'.
> >
> > My personal rules:
> >
> > 1. Only omit braces for the innermost if (when applicable), and only if it does not have
> > an associated else;
> > 2. Braces and else go on their own lines;
> > 3. Braces line up with the if and else;
> >
> > To wit:
> >
> > if ( dblh != dblw )
> > {
> > if ( dblh )
> > {
> > gfx_flags |= GFX_DBL_H;
> > }
> > else
> > {
> > gfx_flags |= GFX_DBL_W;
> > }
> > }
> >
> > Unambiguous.
>
> So was the original!
>
Not according to whomever reviewed Anton's code. At a glance, it looks like
gfx_flags |= GFX_DBL_W;
belongs to the "if (dblh)" branch. The first time I scanned the code I missed the "else"
keyword altogether. That's why I put "else" on its own line, always.
> > It's clear which if the else belongs to, it's clear which branch is taken
> > based on the conditions, etc.
>
Not to my middle-aged eyes.
> How could it not be clear which "if" the "else" is part of? Now I can
> imagine some people who might not know (which is not quite the same
> thing), but I really don't want such a person maintaining /any/ code.
>
> You hear a lot about the crisis in software (or you used to -- maybe
> it's fixed now!). There's no hope, though, if software is being altered
> by people who don't understand the original code as posted.
>
On an average day I'm helping support troubleshoot multiple issues, clearing at least
one bug, writing up deployment tickets, going to meetings, and writing a new interface. On
top of all that, my eyes are almost 55 years old and don't work so well anymore.
If I have to spend more than a few seconds trying to parse out what you *meant* based on
some dodgy formatting, I am going to kick it back to you and tell you to make it explicit.
> > You won't introduce a bug if you decide to add a logging
> > statement to either branch.
>
> That's not really what you mean. You mean it's easier to do so, or at
> least less error prone in the face of people who just type code without
> knowing what the language. (You can only add a statement to either
> branch if you add {}s.)
You can add statements to either branch without adding the {}s, your code just won't
work properly. Nothing's physically stopping you from writing
if ( a )
do_something();
do_another_thing();
It's just that if you're expecting do_another_thing() only to execute when a is true, then
you're going to be bitterly disappointed.
It happens. It's happened a *lot* over the last 30 years. So I'm going to tell you to use
braces everywhere all the time. There's one case where I *won't* kick back code
that doesn't use braces for an "if" branch, but otherwise they need to be there.
>
> > It sacrifices some vertical space (and a little visual clutter), but
> > nobody's going to come tracking you down later to ask what the hell
> > you meant.
>
> It would be simpler to track down someone who knows C's syntax first.
>
Yeah, suppose the code was formatted as
if ( a )
if ( b )
do_something();
else
do_something_else();
What did I mean to do? Not "what does this syntax mean", but what was my *intent*? How
would you tell?
This isn't a syntax issue. This is a clarity issue. Using braces everywhere all the time
makes your intent clear. Consistent formatting with clearly indicated scope boundaries
makes your intent clear.
If your code is not clear *at a glance*, then I'm not going to waste my limited time with it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-06 15:43 -0800 |
| Message-ID | <87mu9v1dtv.fsf@nosuchdomain.example.com> |
| In reply to | #149805 |
John Bode <jfbode1029@gmail.com> writes:
[...]
> You can add statements to either branch without adding the {}s, your
> code just won't work properly. Nothing's physically stopping you from
> writing
>
> if ( a )
> do_something();
> do_another_thing();
>
> It's just that if you're expecting do_another_thing() only to execute
> when a is true, then you're going to be bitterly disappointed.
[...]
I once had to deal with some code that looked like:
if (condition)
do_something();
do_another_thing();
When I took a closer look, I realized that it looked like:
if (condition)
do_something();
do_another_thing();
to its author, who had different tab settings than I did (4 vs 8
columns). It used an inconsistent mixture of tabs and spaces for
indentation.
Fortunately I was able to reject it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-02-07 11:02 +0100 |
| Message-ID | <r1jcjt$7ca$1@dont-email.me> |
| In reply to | #149808 |
On 07/02/2020 00:43, Keith Thompson wrote:
> John Bode <jfbode1029@gmail.com> writes:
> [...]
>> You can add statements to either branch without adding the {}s, your
>> code just won't work properly. Nothing's physically stopping you from
>> writing
>>
>> if ( a )
>> do_something();
>> do_another_thing();
>>
>> It's just that if you're expecting do_another_thing() only to execute
>> when a is true, then you're going to be bitterly disappointed.
> [...]
>
> I once had to deal with some code that looked like:
>
> if (condition)
> do_something();
> do_another_thing();
>
> When I took a closer look, I realized that it looked like:
>
> if (condition)
> do_something();
> do_another_thing();
>
> to its author, who had different tab settings than I did (4 vs 8
> columns). It used an inconsistent mixture of tabs and spaces for
> indentation.
>
> Fortunately I was able to reject it.
>
With braces, there would never have been a doubt about what the code
did, or what it was intended to do - even with a quick reading and with
mixed spaces and tabs and different tab settings.
I'm with John here. I insist on braces except for a few very simple
cases on the same line, such as :
if (condition) break;
It simply and quickly eliminates several classes of very common
potential errors - in terms of writing code that doesn't do what the
author wanted, of misinterpreting code when reading it, and in terms of
maintaining and modifying code.
Programmers are human. They make mistakes in reading and writing code.
They make fewer mistakes if you have simple, clear rules to make life
easier. Then they can spend their time on useful activities like
drinking coffee, going to meetings, and hanging out on Usenet instead of
staring at the same code trying to figure out if it does what the author
intended it to do.
To me, the requirement of braces in conditionals and loops is a no-brainer.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-02-07 15:24 +0000 |
| Message-ID | <9jf%F.196563$5o5.191340@fx41.iad> |
| In reply to | #149817 |
David Brown <david.brown@hesbynett.no> writes:
>On 07/02/2020 00:43, Keith Thompson wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>> [...]
>>> You can add statements to either branch without adding the {}s, your
>>> code just won't work properly. Nothing's physically stopping you from
>>> writing
>>>
>>> if ( a )
>>> do_something();
>>> do_another_thing();
>>>
>>> It's just that if you're expecting do_another_thing() only to execute
>>> when a is true, then you're going to be bitterly disappointed.
>> [...]
>>
>> I once had to deal with some code that looked like:
>>
>> if (condition)
>> do_something();
>> do_another_thing();
>>
>> When I took a closer look, I realized that it looked like:
>>
>> if (condition)
>> do_something();
>> do_another_thing();
>>
>> to its author, who had different tab settings than I did (4 vs 8
>> columns). It used an inconsistent mixture of tabs and spaces for
>> indentation.
>>
>> Fortunately I was able to reject it.
>>
>
>With braces, there would never have been a doubt about what the code
>did, or what it was intended to do - even with a quick reading and with
>mixed spaces and tabs and different tab settings.
>
>I'm with John here. I insist on braces except for a few very simple
>cases on the same line, such as :
>
> if (condition) break;
Same here; but it dates back to the days of card decks when repunching
a card to add the '{' (or BEGIN keyword in those days)' was a PITA :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-07 23:03 +0000 |
| Message-ID | <87pneqm256.fsf@bsb.me.uk> |
| In reply to | #149824 |
scott@slp53.sl.home (Scott Lurndal) writes:
> David Brown <david.brown@hesbynett.no> writes:
<cut>
>>I'm with John here. I insist on braces except for a few very simple
>>cases on the same line, such as :
>>
>> if (condition) break;
>
> Same here; but it dates back to the days of card decks when repunching
> a card to add the '{' (or BEGIN keyword in those days)' was a PITA :-)
Did you not have a pile of BEGIN cards and a pile of END cards
on your desk so you could just add them where needed?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-02-07 23:59 +0000 |
| Message-ID | <KRm%F.336167$Gh7.81098@fx45.iad> |
| In reply to | #149832 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
><cut>
>>>I'm with John here. I insist on braces except for a few very simple
>>>cases on the same line, such as :
>>>
>>> if (condition) break;
>>
>> Same here; but it dates back to the days of card decks when repunching
>> a card to add the '{' (or BEGIN keyword in those days)' was a PITA :-)
>
>Did you not have a pile of BEGIN cards and a pile of END cards
>on your desk so you could just add them where needed?
The problem wasn't with the begin/end so much as removing the
'then' code following the if, since it needed to be _after_ the begin.
Now, I never wrote code that way, but I had to maintain some stuff
from the late 60's for a while in the early 80's.
My style, which made inserting code easier, was more like:
PROCEDURE Directory; 00023000
BEGIN 00024000
LABEL Eof, Done; 00025000
&& 00026000
&& Do a directory of the tape 00027000
&& 00028000
00029000
DoDir := TRUE; 00029500
OPEN OUT Printer; 00030000
PrintRec := [ALL] " "; 00031000
DO_ 00032000
OPEN IN Posters NO REWIND; 00033000
READ Posters [Done]; 00033500
IF Posters.+204.2 EQL @FF@ 00034000
THEN 00035000
EXITLOOP; 00036000
DO_ 00037000
IF Posters.+203.1 = @A@ && Short block 00039000
THEN_ 00040000
PrintRec.40 := "BSW.1 = @A@, Short Block"; 00041000
WRITE Printer SINGLE; 00042000
FI; 00043000
IF Posters.+216.6 NEQ Posters.+234.6 00044000
THEN_ 00045000
PrintRec.40 := "BSW.1 NEQ @A@ Short Block"; 00046000
WRITE Printer SINGLE; 00047000
FI; 00048000
READ Posters [Eof]; 00048500
OD; 00049000
Eof: 00050000
CLOSE Posters NO REWIND; 00051000
TapeLabel.+09.6.UA := " "; 00052000
OD; 00053000
Done: 00053500
CLOSE Posters RELEASE; 00054000
CLOSE Printer RELEASE; 00055000
STOP; 00056000
00057000
Some of the older (mid 70s) code (from a document markup application):
@PAGE 02254000
PROC_ MARK_NEW_HOLDOVERS_IN_REPRINTS; 02255000
BODY_ 02256000
IF_ print_reprint_line > 0 02257000
THEN_ IF_ print_line.66 ^= " " OR print_line.+66.66 ^= " " 02258000
THEN_ IX1 := current_rmargin + current_rmargin 02259000
+ u_tally + u_tally + b_tally + b_tally 02260000
+ o_tally + o_tally + 10; 02261000
DO_ WHILE_ (print_line.IX1.-10.10 = " ") 02262000
dec (x1,20) 02263000
OD; 02264000
DO_ WHILE_ (print_line.IX1.-1.1 = " ") 02265000
dec (x1,2) 02266000
OD; 02267000
FI; 02268000
FI; &mark end if holding ovr 02269000
02270000
IF_ doing_underscore 02271000
THEN_ underscore_line.IX1.1 := underscorer; 02272000
current_u_type := u_type; 02273000
u_type_held_over := u_type 02274000
FI; 02275000
IF_ doing_bold 02276000
THEN_ bold_line.IX1.1 := bolder; 02277000
current_b_count := bold_count; 02278000
bold_count_held_over := bold_count 02279000
FI; 02280000
IF_ doing_overprint 02281000
THEN_ overprint_line.IX1.1 := overprinter; 02282000
current_o_char := overprint_char; 02283000
overprint_char_held_over := overprint_char 02284000
FI; 02285000
CORP_; 02286000
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-02-08 00:16 +0000 |
| Message-ID | <K5n%F.179909$sH2.166997@fx18.am4> |
| In reply to | #149834 |
On 07/02/2020 23:59, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>>> I'm with John here. I insist on braces except for a few very simple
>>>> cases on the same line, such as :
>>>>
>>>> if (condition) break;
>>>
>>> Same here; but it dates back to the days of card decks when repunching
>>> a card to add the '{' (or BEGIN keyword in those days)' was a PITA :-)
>>
>> Did you not have a pile of BEGIN cards and a pile of END cards
>> on your desk so you could just add them where needed?
>
> The problem wasn't with the begin/end so much as removing the
> 'then' code following the if, since it needed to be _after_ the begin.
>
> Now, I never wrote code that way, but I had to maintain some stuff
> from the late 60's for a while in the early 80's.
>
> My style, which made inserting code easier, was more like:
>
> PROCEDURE Directory; 00023000
> BEGIN 00024000
> LABEL Eof, Done; 00025000
> && 00026000
> && Do a directory of the tape 00027000
> && 00028000
> 00029000
> DoDir := TRUE; 00029500
> OPEN OUT Printer; 00030000
> PrintRec := [ALL] " "; 00031000
> DO_ 00032000
> OPEN IN Posters NO REWIND; 00033000
> READ Posters [Done]; 00033500
> IF Posters.+204.2 EQL @FF@ 00034000
> THEN 00035000
> EXITLOOP; 00036000
If there a FI missing here, or is that only when you use THEN_ rather
than THEN?
If so it would better to consistently require FI, as otherwise you'd get
the same problem with C when you have:
if (cond)
S1;
and decide to extend that to:
if (cond)
S1;
S2;
> IF Posters.+203.1 = @A@ && Short block 00039000
> THEN_ 00040000
> PrintRec.40 := "BSW.1 = @A@, Short Block"; 00041000
> WRITE Printer SINGLE; 00042000
> FI; 00043000
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-02-08 02:26 +0000 |
| Message-ID | <1%o%F.230502$Zw7.168143@fx34.iad> |
| In reply to | #149835 |
Bart <bc@freeuk.com> writes:
>On 07/02/2020 23:59, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>> <cut>
>>>>> I'm with John here. I insist on braces except for a few very simple
>>>>> cases on the same line, such as :
>>>>>
>>>>> if (condition) break;
>>>>
>>>> Same here; but it dates back to the days of card decks when repunching
>>>> a card to add the '{' (or BEGIN keyword in those days)' was a PITA :-)
>>>
>>> Did you not have a pile of BEGIN cards and a pile of END cards
>>> on your desk so you could just add them where needed?
>>
>> The problem wasn't with the begin/end so much as removing the
>> 'then' code following the if, since it needed to be _after_ the begin.
>>
>> Now, I never wrote code that way, but I had to maintain some stuff
>> from the late 60's for a while in the early 80's.
>>
>> My style, which made inserting code easier, was more like:
>>
>> PROCEDURE Directory; 00023000
>> BEGIN 00024000
>> LABEL Eof, Done; 00025000
>> && 00026000
>> && Do a directory of the tape 00027000
>> && 00028000
>> 00029000
>> DoDir := TRUE; 00029500
>> OPEN OUT Printer; 00030000
>> PrintRec := [ALL] " "; 00031000
>> DO_ 00032000
>> OPEN IN Posters NO REWIND; 00033000
>> READ Posters [Done]; 00033500
>> IF Posters.+204.2 EQL @FF@ 00034000
>> THEN 00035000
>> EXITLOOP; 00036000
>
>If there a FI missing here, or is that only when you use THEN_ rather
>than THEN?
>
Actually, the keywords ending in _ are macros that compiled
into a library used by the above code.
?LI SYSTEM/OPERATOR
?COMPILE LBPL68 WITH BPL LIB MEM +50
?DATA CARD
$CARD LST1
LBPL68:
BEGIN
@LIBR "BPL68"
DEFINE IN_ = BEGIN BEGIN UNSEGMENTED #,
OUT_ = END ELSE BEGIN UNSEGMENTED #,
ELSE_ = END ELSE BEGIN UNSEGMENTED #,
ELIF_ = END ELSE IF #,
THEN_ = THEN BEGIN UNSEGMENTED #,
UNTIL_(C) = ; IF C THEN EXITLOOP; #,
WHILE_(C) = ; IF NOT C THEN EXITLOOP; #,
END_ = END #,
FI_ = FI #,
OD_ = OD #,
ESAC_ = ESAC #,
EXITBLOCK_ = EXITBLOCK #,
EXITCOND_ = EXITCOND #,
EXITLOOP_ = EXITLOOP #,
EXITCASE_ = EXITCASE #,
GOTOTOPLOOP_ = TOPLOOP #,
TOPLOOP_ = TOPLOOP #;
@LIBR
END.
?END
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web