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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2020-02-08 17:07 -0600 |
| Message-ID | <r1neta$q60$2@dont-email.me> |
| In reply to | #149808 |
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.
>
There's something to be said for having a code formatter/pretty printer
in the code checkin process. At home, I use Artistic Style.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-02-08 23:17 +0000 |
| Message-ID | <xkH%F.855418$GFe.579463@fx12.am4> |
| In reply to | #149871 |
On 08/02/2020 23:07, Les Cargill wrote:
> 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.
>>
>
> There's something to be said for having a code formatter/pretty printer
> in the code checkin process. At home, I use Artistic Style.
>
But if you pass it this code:
if (cond)
s1;
s2;
if (cond)
if (cond2)
s1;
else
s2;
then probably it will produce:
if (cond)
s1;
s2;
if (cond)
if (cond2)
s1;
else
s2;
This looks fine. But the original suggests the intentions of the
programmer may have been different.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2020-02-08 18:32 -0600 |
| Message-ID | <r1nju0$lrl$2@dont-email.me> |
| In reply to | #149872 |
Bart wrote:
> On 08/02/2020 23:07, Les Cargill wrote:
>> 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.
>>>
>>
>> There's something to be said for having a code formatter/pretty printer
>> in the code checkin process. At home, I use Artistic Style.
>>
>
> But if you pass it this code:
>
> if (cond)
> s1;
> s2;
>
> if (cond)
> if (cond2)
> s1;
> else
> s2;
>
> then probably it will produce:
>
> if (cond)
> s1;
> s2;
>
> if (cond)
> if (cond2)
> s1;
> else
> s2;
>
> This looks fine. But the original suggests the intentions of the
> programmer may have been different.
Still, having the indentation reflect what it is is (IMO)
preferable.
I'm with the others - braces should be required.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-02-09 09:32 -0800 |
| Message-ID | <99a53399-731d-4b5a-abed-8ff8856a1bb6@googlegroups.com> |
| In reply to | #149874 |
On Sunday, 9 February 2020 00:32:08 UTC, Les Cargill wrote:
> Bart wrote:
> > On 08/02/2020 23:07, Les Cargill wrote:
> >> 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.
> >>>
> >>
> >> There's something to be said for having a code formatter/pretty printer
> >> in the code checkin process. At home, I use Artistic Style.
> >>
> >
> > But if you pass it this code:
> >
> > if (cond)
> > s1;
> > s2;
> >
> > if (cond)
> > if (cond2)
> > s1;
> > else
> > s2;
> >
> > then probably it will produce:
> >
> > if (cond)
> > s1;
> > s2;
> >
> > if (cond)
> > if (cond2)
> > s1;
> > else
> > s2;
> >
> > This looks fine. But the original suggests the intentions of the
> > programmer may have been different.
>
> Still, having the indentation reflect what it is is (IMO)
> preferable.
>
> I'm with the others - braces should be required.
>
Code has to mean something in human terms if it is to be useful, with
the exception of brief snippets posted to comp.lang.c to illustrate a
point.
So to fix a bug, you needs to know what he intended as well as what he
actually wrote, assuming that the discrepancy is the source of the
bug. You can't privilege one above the other.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-16 07:10 -0800 |
| Message-ID | <867e0mftzp.fsf@linuxsc.com> |
| In reply to | #149871 |
Les Cargill <lcargill99@comcast.com> writes: > There's something to be said for having a code formatter/pretty > printer in the code checkin process. IME that's not a good idea. Any reasonably large program invariably contains some deliberate "violations" of the layout conventions being followed, and automated formatters mess those up. Such cases aren't just contrariness on the part of whoever is doing the programming: just as in writing English prose, sometimes it is important to break a style rule, to get a better result; taking a slavishly mechanical attitude has problems if followed rigidly and without exception. Code formatters are great for getting an unruly code base "shipshape and Bristol fashion" before editing starts. Not so much later during normal development.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-07 01:26 +0000 |
| Message-ID | <874kw3nq6s.fsf@bsb.me.uk> |
| In reply to | #149805 |
John Bode <jfbode1029@gmail.com> writes:
> 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.
You are using ambiguous to mean "can be misread". I see, and I agree.
I am sure there are people who can misread almost any code but that
would turn into a discussion of degree. I thought you meant something
else by "unambiguous".
>> > 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.
Mine are old-aged and I need strong reading glasses, but I can see the
else quite clearly. It's not easy to code for other people's eyes. I
don't think I've come across anyone saying the they need the else on a
line by itself in order to see it clearly.
>> 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.
The boss is always right!
>> > 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,
We are just disagreeing about words. I don't think that's going to be
productive other than maybe highlighting how our words can be
misunderstood.
> your code just won't
> work properly. Nothing's physically stopping you from writing
>
> if ( a )
> do_something();
> do_another_thing();
This change (as I am sure you know) has not "added statements to either
branch". I just think you could be be clearer in your wording. We both
know what's happening in the code.
> 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.
This may be why there is such a crisis in software development. I can't
imagine anyone I've worked with doing this (i.e. just adding a line
thining it's goinf to be part of the "if"), but maybe I've just been
lucky. Maybe companies have no choice but to hire people to work on C
code who might just type that line above, thinking it's adding code to a
branch of the if.
What's more, you are suggesting that code errors of this sort frequently
survive long enough for someone like you to see them. Whilst C programs
can have subtle errors that go uncaught for some time, your people
should have a testing regime in place so that basic errors of logic get
caught immediately.
> 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?
Why would I care? (I am being serious.) If the code is failing some
tests, I will look at what the code actually does whilst trying as hard
as possible to ignore what you might have meant. Nothing else matters.
If the code is passing all the tests, I'd probably leave it alone. If,
in the case of apparently correct code, I were to speculate on what you
meant, it would be both wise (and polite!) to assume you meant exactly
what the syntax says.
> 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.
Why do you care about the intent? What matters is what the code
actually does. (There is another kind of clarity that relates to
readability but that does not seem to be what you are stressing here.)
> If your code is not clear *at a glance*, then I'm not going to waste
> my limited time with it.
Of course. Neither of us would want that!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-02-07 11:30 +0100 |
| Message-ID | <r1je7h$5fl$1@dont-email.me> |
| In reply to | #149810 |
On 07/02/2020 02:26, Ben Bacarisse wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>> John Bode <jfbode1029@gmail.com> writes:
>>>
>
> Mine are old-aged and I need strong reading glasses, but I can see the
> else quite clearly. It's not easy to code for other people's eyes. I
> don't think I've come across anyone saying the they need the else on a
> line by itself in order to see it clearly.
I put the braces on the same line as the "else":
if (condition) {
do_this();
} else if (another_condition) {
do_that();
} else {
do_something_different();
}
I don't see the need to put "else" on its own line entirely, but I would
never have it later in a line. (Well, /almost/ never - rules shouldn't
be /too/ rigid. But I would need an extremely good reason for breaking
this one.)
>
>>> 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.
>
> The boss is always right!
>
>>>> 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,
>
> We are just disagreeing about words. I don't think that's going to be
> productive other than maybe highlighting how our words can be
> misunderstood.
>
>> your code just won't
>> work properly. Nothing's physically stopping you from writing
>>
>> if ( a )
>> do_something();
>> do_another_thing();
>
> This change (as I am sure you know) has not "added statements to either
> branch". I just think you could be be clearer in your wording. We both
> know what's happening in the code.
And I am sure we all know that people /do/ make this kind of mistake.
>
>> 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.
>
> This may be why there is such a crisis in software development. I can't
> imagine anyone I've worked with doing this (i.e. just adding a line
> thining it's goinf to be part of the "if"), but maybe I've just been
> lucky. Maybe companies have no choice but to hire people to work on C
> code who might just type that line above, thinking it's adding code to a
> branch of the if.
I am not sure that this is just about the type of people that are hired
to write code. All programmers are human, and make mistakes on
occasion. (As the saying goes, "To err is human - to really screw
things up takes a computer.") It is common sense to code in a way that
reduces the risk of mistakes or the consequences of mistakes - balanced
with all other aspects of code readability, of course.
>
> What's more, you are suggesting that code errors of this sort frequently
> survive long enough for someone like you to see them. Whilst C programs
> can have subtle errors that go uncaught for some time, your people
> should have a testing regime in place so that basic errors of logic get
> caught immediately.
Of course it is important to have good test regimes in place - noting
again that everyone involved is human and tests are never perfect. In
particular, testing can never prove the absence of bugs, but only prove
their presence.
However, it is always cheaper to write the code without bugs than to
find the bugs in testing. It is always cheaper to have bugs found
during editing, compiling or static analysis than in testing, code
reviews, or any other stage of the process.
Put the braces in, and the bug here cannot happen. That is a win in any
development process.
>
>> 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?
>
> Why would I care? (I am being serious.) If the code is failing some
> tests, I will look at what the code actually does whilst trying as hard
> as possible to ignore what you might have meant. Nothing else matters.
Nonsense.
Good code is not "whatever crap happens to work in testing". Depending
as always on budgets, time schedules, and "what the boss says", code is
not good unless it is /clearly/ correct. It has to be correct according
to appropriate standards - it should still be correct when there is a
change in the compiler, or settings, or target, if it needs to be
portable. It should fit the coding standards of the company or project.
It should be maintainable, re-useable, and have appropriate documentation.
What you need beyond "it worked when I tried it" varies enormously from
application to application. You hold the software in an aircraft to
different standards from a "snake" game on a PC.
But some things are so simple and low cost, but make such a difference
to code quality, that they should not be in question. It is one thing
to take short-cuts, or be lax about documentation (who isn't?) - sloppy
coding like that example never has a home.
>
> If the code is passing all the tests, I'd probably leave it alone. If,
> in the case of apparently correct code, I were to speculate on what you
> meant, it would be both wise (and polite!) to assume you meant exactly
> what the syntax says.
>
>> 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.
>
> Why do you care about the intent? What matters is what the code
> actually does. (There is another kind of clarity that relates to
> readability but that does not seem to be what you are stressing here.)
>
Again, I disagree.
Code is correct when it does what the author intended. (It is, of
course, important that the author intends the right thing - but that's a
higher level issue in specifying the task.) If the author's intentions
are not clear in the code, or apparently disagree with the working of
the code, the code is wrong. The code is wrong even if it passes all
the tests you try. (IMHO, of course.)
In another discussion in another group, we have been looking at a
function that has a very small chance of a race condition error that
could only occur if a thread gets pre-empted within a sequence of three
or four instructions that are run once every 49 days. The original code
will pass all its tests - you'll never hit that bug in testing. But
with enough systems delivered it might occur in practice. The code
would test fine, but is still wrong.
>> If your code is not clear *at a glance*, then I'm not going to waste
>> my limited time with it.
>
> Of course. Neither of us would want that!
>
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2020-02-07 05:36 -0800 |
| Message-ID | <cf068ed4-0904-4bb5-8001-a61620b660f3@googlegroups.com> |
| In reply to | #149819 |
On Friday, February 7, 2020 at 2:30:51 AM UTC-8, David Brown wrote:
> On 07/02/2020 02:26, Ben Bacarisse wrote:
> > John Bode <jfbode1029@gmail.com> writes:
> >
> >> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
> >>> John Bode <jfbode1029@gmail.com> writes:
> >>>
>
> >
> > Mine are old-aged and I need strong reading glasses, but I can see the
> > else quite clearly. It's not easy to code for other people's eyes. I
> > don't think I've come across anyone saying the they need the else on a
> > line by itself in order to see it clearly.
>
> I put the braces on the same line as the "else":
>
> if (condition) {
> do_this();
> } else if (another_condition) {
> do_that();
> } else {
> do_something_different();
> }
>
> I don't see the need to put "else" on its own line entirely, but I would
> never have it later in a line. (Well, /almost/ never - rules shouldn't
> be /too/ rigid. But I would need an extremely good reason for breaking
> this one.)
>
I've put else on its own line when developing a first draft of the code and debugging it. Ie, I sometimes will do
if (condition) {
}//end of first if (if this if statements happens to be nested)
else if (another_condition){
}//??Possible expected value when I hand traced the code vs the actual value.
else {
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-07 23:36 +0000 |
| Message-ID | <87k14ym0lg.fsf@bsb.me.uk> |
| In reply to | #149819 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/02/2020 02:26, Ben Bacarisse wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>>
>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>
>
>>
>> Mine are old-aged and I need strong reading glasses, but I can see the
>> else quite clearly. It's not easy to code for other people's eyes. I
>> don't think I've come across anyone saying the they need the else on a
>> line by itself in order to see it clearly.
>
> I put the braces on the same line as the "else":
>
> if (condition) {
> do_this();
> } else if (another_condition) {
> do_that();
> } else {
> do_something_different();
> }
>
> I don't see the need to put "else" on its own line entirely, but I would
> never have it later in a line. (Well, /almost/ never - rules shouldn't
> be /too/ rigid. But I would need an extremely good reason for breaking
> this one.)
We have these threads every now and then an though it's fun to see what
everyone else likes and dislikes, John Bode said that it was not clear
which if the else belonged to. I found that very surprising. Do you
think it's not clear which if the else belongs to?
The fact that he could not see then else came up (oddly) later. Did you
not see it?
>
>>
>>>> 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.
>>
>> The boss is always right!
>>
>>>>> 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,
>>
>> We are just disagreeing about words. I don't think that's going to be
>> productive other than maybe highlighting how our words can be
>> misunderstood.
>>
>>> your code just won't
>>> work properly. Nothing's physically stopping you from writing
>>>
>>> if ( a )
>>> do_something();
>>> do_another_thing();
>>
>> This change (as I am sure you know) has not "added statements to either
>> branch". I just think you could be be clearer in your wording. We both
>> know what's happening in the code.
>
> And I am sure we all know that people /do/ make this kind of mistake.
>
>>
>>> 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.
>>
>> This may be why there is such a crisis in software development. I can't
>> imagine anyone I've worked with doing this (i.e. just adding a line
>> thining it's goinf to be part of the "if"), but maybe I've just been
>> lucky. Maybe companies have no choice but to hire people to work on C
>> code who might just type that line above, thinking it's adding code to a
>> branch of the if.
>
> I am not sure that this is just about the type of people that are hired
> to write code. All programmers are human, and make mistakes on
> occasion. (As the saying goes, "To err is human - to really screw
> things up takes a computer.") It is common sense to code in a way that
> reduces the risk of mistakes or the consequences of mistakes - balanced
> with all other aspects of code readability, of course.
>
>>
>> What's more, you are suggesting that code errors of this sort frequently
>> survive long enough for someone like you to see them. Whilst C programs
>> can have subtle errors that go uncaught for some time, your people
>> should have a testing regime in place so that basic errors of logic get
>> caught immediately.
>
> Of course it is important to have good test regimes in place - noting
> again that everyone involved is human and tests are never perfect. In
> particular, testing can never prove the absence of bugs, but only prove
> their presence.
But in the case in point there is a bug! People do write silly things
like putting code next to branch of an if whilst forgetting to add the
{}s. But the result is code with a bug that will be found in the very
first test run. This is either a non-issue (as I hope it would be in
most production environments), or it signals that something else is
seriously wrong.
I get the feeling people like to come over all "you'd be fired if you
wrote code like that for me" sometimes. It's often overstating the
case.
> However, it is always cheaper to write the code without bugs than to
> find the bugs in testing. It is always cheaper to have bugs found
> during editing, compiling or static analysis than in testing, code
> reviews, or any other stage of the process.
Of course. And my editor would show up that bug immediately. So would
the compiler I use. So we must be talking about an environment where
the editor does not help, the compiler won't help and the tests are no
good. It's all getting a bit niche...
> Put the braces in, and the bug here cannot happen. That is a win in any
> development process.
There is a cost in making your staff follow the ladybird book of C style.
>>
>>> 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?
>>
>> Why would I care? (I am being serious.) If the code is failing some
>> tests, I will look at what the code actually does whilst trying as hard
>> as possible to ignore what you might have meant. Nothing else matters.
>
> Nonsense.
>
> Good code is not "whatever crap happens to work in testing". Depending
> as always on budgets, time schedules, and "what the boss says", code is
> not good unless it is /clearly/ correct. It has to be correct according
> to appropriate standards - it should still be correct when there is a
> change in the compiler, or settings, or target, if it needs to be
> portable. It should fit the coding standards of the company or project.
> It should be maintainable, re-useable, and have appropriate
> documentation.
I don't think I said what you think I am saying -- possibly because you
cut what I said in two and answered each part separately, instead of
considering the combined point I was making.
> What you need beyond "it worked when I tried it" varies enormously from
> application to application. You hold the software in an aircraft to
> different standards from a "snake" game on a PC.
>
> But some things are so simple and low cost, but make such a difference
> to code quality, that they should not be in question. It is one thing
> to take short-cuts, or be lax about documentation (who isn't?) - sloppy
> coding like that example never has a home.
>>
>> If the code is passing all the tests, I'd probably leave it alone. If,
>> in the case of apparently correct code, I were to speculate on what you
>> meant, it would be both wise (and polite!) to assume you meant exactly
>> what the syntax says.
>>
>>> 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.
>>
>> Why do you care about the intent? What matters is what the code
>> actually does. (There is another kind of clarity that relates to
>> readability but that does not seem to be what you are stressing here.)
>>
>
> Again, I disagree.
>
> Code is correct when it does what the author intended. (It is, of
> course, important that the author intends the right thing - but that's a
> higher level issue in specifying the task.) If the author's intentions
> are not clear in the code, or apparently disagree with the working of
> the code, the code is wrong. The code is wrong even if it passes all
> the tests you try. (IMHO, of course.)
>
> In another discussion in another group, we have been looking at a
> function that has a very small chance of a race condition error that
> could only occur if a thread gets pre-empted within a sequence of three
> or four instructions that are run once every 49 days. The original code
> will pass all its tests - you'll never hit that bug in testing. But
> with enough systems delivered it might occur in practice. The code
> would test fine, but is still wrong.
This seems to have gone off on a tangent, and I can't see how it
addresses what I wrote.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-02-08 17:20 +0100 |
| Message-ID | <r1mn3m$dtk$1@dont-email.me> |
| In reply to | #149833 |
On 08/02/2020 00:36, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/02/2020 02:26, Ben Bacarisse wrote:
>>> John Bode <jfbode1029@gmail.com> writes:
>>>
>>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>
>>
>>>
>>> Mine are old-aged and I need strong reading glasses, but I can see the
>>> else quite clearly. It's not easy to code for other people's eyes. I
>>> don't think I've come across anyone saying the they need the else on a
>>> line by itself in order to see it clearly.
>>
>> I put the braces on the same line as the "else":
>>
>> if (condition) {
>> do_this();
>> } else if (another_condition) {
>> do_that();
>> } else {
>> do_something_different();
>> }
>>
>> I don't see the need to put "else" on its own line entirely, but I would
>> never have it later in a line. (Well, /almost/ never - rules shouldn't
>> be /too/ rigid. But I would need an extremely good reason for breaking
>> this one.)
>
> We have these threads every now and then an though it's fun to see what
> everyone else likes and dislikes, John Bode said that it was not clear
> which if the else belonged to. I found that very surprising. Do you
> think it's not clear which if the else belongs to?
>
I know which "if" the "else" belonged to. But I don't think the format
of the code matches the semantics of the code, and I think that is bad
style - it risks confusion.
Sometimes there can be a difficult bit of code, and understanding it
will take time and effort. But for a lot of code, you can write it
clearly and simply in a way that is immediately obvious even at a very
quick reading. I cannot fathom why anyone would want to write code that
is less easily understood than necessary.
There are many other ways in which it could have been formatted and
still have the formatting and semantics match up well. Things like how
the braces and "else" are split up on lines is a matter of details and
personal preference, rather than principle.
> The fact that he could not see then else came up (oddly) later. Did you
> not see it?
>
Yes, I saw it. Being able to read the code and understand it is not the
same as thinking it is well-written code.
I expect you make a point of using correct spelling in your code. Why
do you do that, when the compiler doesn't care and the code means the
same thing as long as the spelling is consistent? You do it because it
is simpler and clearer to understand.
If I write "int x = 126 - 26;", it is unambiguous and you can understand
it initialises "x" to 100. But is it written in a clear way that makes
it easy to understand at a glance? Does it convey to the human reader
what the programmer was thinking? It leaves the reader wondering if
there is some extra significance in these numbers - why was the code
written that way? If I later want to change the value to 120, should I
change it to "int x = 120;", or "int x = 146 - 26;", or "int x = 126 - 6;" ?
Code is not just about what it means to the compiler - it is about human
interaction too.
>>>
>>> What's more, you are suggesting that code errors of this sort frequently
>>> survive long enough for someone like you to see them. Whilst C programs
>>> can have subtle errors that go uncaught for some time, your people
>>> should have a testing regime in place so that basic errors of logic get
>>> caught immediately.
>>
>> Of course it is important to have good test regimes in place - noting
>> again that everyone involved is human and tests are never perfect. In
>> particular, testing can never prove the absence of bugs, but only prove
>> their presence.
>
> But in the case in point there is a bug! People do write silly things
> like putting code next to branch of an if whilst forgetting to add the
> {}s. But the result is code with a bug that will be found in the very
> first test run. This is either a non-issue (as I hope it would be in
> most production environments), or it signals that something else is
> seriously wrong.
How many programs are written with /complete/ test coverage? I expect
that if you round to the nearest tenth of a percent, the answer is 0%.
This kind of thing has caused bugs that escaped into the wild - in code
that was reviewed, heavily tested, and used massively in large numbers
of systems.
Write your code in a way that minimises the risk of bugs. /Then/ test it.
>
> I get the feeling people like to come over all "you'd be fired if you
> wrote code like that for me" sometimes. It's often overstating the
> case.
That certainly would be overstating the case. (That may be because I
live in Norway - you have to do a great deal worse here than write poor
code to be fired!). To me, this is a teaching opportunity, not a chance
to blame, ridicule or fire people. It is a chance to explain a better
way of writing code.
>
>> However, it is always cheaper to write the code without bugs than to
>> find the bugs in testing. It is always cheaper to have bugs found
>> during editing, compiling or static analysis than in testing, code
>> reviews, or any other stage of the process.
>
> Of course. And my editor would show up that bug immediately. So would
> the compiler I use. So we must be talking about an environment where
> the editor does not help, the compiler won't help and the tests are no
> good. It's all getting a bit niche...
A lot of people use less powerful tools. Some do so from ignorance,
some do so because they have no choice, some do so from stubborn
determination to remain in the previous century.
There are many layers between the programmer and the final shipping that
can help against bugs. Different layers are better at catching
different types of bugs. Use them all (within the possibilities of
budget, experience, tools, etc.). Good testing, good editors, and good
static analysis are some of these layers. But so is good coding
practice and good coding standards.
>
>> Put the braces in, and the bug here cannot happen. That is a win in any
>> development process.
>
> There is a cost in making your staff follow the ladybird book of C style.
>
It is not nearly as high as the cost of allowing staff to write
smart-arse code.
There is a happy medium to be found, and it is not the same for all
companies or projects.
But for some habits - like using braces - the cost is utterly
negligible, and the benefits can be very real.
>>>
>>>> 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?
>>>
>>> Why would I care? (I am being serious.) If the code is failing some
>>> tests, I will look at what the code actually does whilst trying as hard
>>> as possible to ignore what you might have meant. Nothing else matters.
>>
>> Nonsense.
>>
>> Good code is not "whatever crap happens to work in testing". Depending
>> as always on budgets, time schedules, and "what the boss says", code is
>> not good unless it is /clearly/ correct. It has to be correct according
>> to appropriate standards - it should still be correct when there is a
>> change in the compiler, or settings, or target, if it needs to be
>> portable. It should fit the coding standards of the company or project.
>> It should be maintainable, re-useable, and have appropriate
>> documentation.
>
> I don't think I said what you think I am saying -- possibly because you
> cut what I said in two and answered each part separately, instead of
> considering the combined point I was making.
Perhaps that is the case. Sorry if I have misunderstood you here.
>
>> What you need beyond "it worked when I tried it" varies enormously from
>> application to application. You hold the software in an aircraft to
>> different standards from a "snake" game on a PC.
>>
>> But some things are so simple and low cost, but make such a difference
>> to code quality, that they should not be in question. It is one thing
>> to take short-cuts, or be lax about documentation (who isn't?) - sloppy
>> coding like that example never has a home.
>>>
>>> If the code is passing all the tests, I'd probably leave it alone. If,
>>> in the case of apparently correct code, I were to speculate on what you
>>> meant, it would be both wise (and polite!) to assume you meant exactly
>>> what the syntax says.
>>>
>>>> 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.
>>>
>>> Why do you care about the intent? What matters is what the code
>>> actually does. (There is another kind of clarity that relates to
>>> readability but that does not seem to be what you are stressing here.)
>>>
>>
>> Again, I disagree.
>>
>> Code is correct when it does what the author intended. (It is, of
>> course, important that the author intends the right thing - but that's a
>> higher level issue in specifying the task.) If the author's intentions
>> are not clear in the code, or apparently disagree with the working of
>> the code, the code is wrong. The code is wrong even if it passes all
>> the tests you try. (IMHO, of course.)
>>
>> In another discussion in another group, we have been looking at a
>> function that has a very small chance of a race condition error that
>> could only occur if a thread gets pre-empted within a sequence of three
>> or four instructions that are run once every 49 days. The original code
>> will pass all its tests - you'll never hit that bug in testing. But
>> with enough systems delivered it might occur in practice. The code
>> would test fine, but is still wrong.
>
> This seems to have gone off on a tangent, and I can't see how it
> addresses what I wrote.
>
It address the "the bug would have shown up in testing" alternative to
writing code more carefully in the first place. But fair enough, it
/is/ somewhat tangential, since it is about a subtle bug rather than
differences in formatting.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-09 02:07 +0000 |
| Message-ID | <875zggms21.fsf@bsb.me.uk> |
| In reply to | #149855 |
This exchange is, I feel, not very productive. You seem to be
attributing to me views I don't have and arguing against those.
In particular, you seem to think I don't value "clarity" in code and,
secondarily, that I think code is for computers not humans. I don't
know how you got that from what I wrote. Maybe I was not clear.
Anyway, I'm going to reply to only a couple of very specific points
because I am not against writing clear code.
David Brown <david.brown@hesbynett.no> writes:
> On 08/02/2020 00:36, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 07/02/2020 02:26, Ben Bacarisse wrote:
>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>
>>>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>
>>>
>>>>
>>>> Mine are old-aged and I need strong reading glasses, but I can see the
>>>> else quite clearly. It's not easy to code for other people's eyes. I
>>>> don't think I've come across anyone saying the they need the else on a
>>>> line by itself in order to see it clearly.
>>>
>>> I put the braces on the same line as the "else":
>>>
>>> if (condition) {
>>> do_this();
>>> } else if (another_condition) {
>>> do_that();
>>> } else {
>>> do_something_different();
>>> }
>>>
>>> I don't see the need to put "else" on its own line entirely, but I would
>>> never have it later in a line. (Well, /almost/ never - rules shouldn't
>>> be /too/ rigid. But I would need an extremely good reason for breaking
>>> this one.)
>>
>> We have these threads every now and then an though it's fun to see what
>> everyone else likes and dislikes, John Bode said that it was not clear
>> which if the else belonged to. I found that very surprising. Do you
>> think it's not clear which if the else belongs to?
>>
>
> I know which "if" the "else" belonged to. But I don't think the
> format of the code matches the semantics of the code, and I think that
> is bad style - it risks confusion.
What is the confusion that is risked? Do you mean thata there are at
least two meanings that could be considered for the original code? If
so, what are those? If not, what is the risk you see?
<cut>
>>>> What's more, you are suggesting that code errors of this sort frequently
>>>> survive long enough for someone like you to see them. Whilst C programs
>>>> can have subtle errors that go uncaught for some time, your people
>>>> should have a testing regime in place so that basic errors of logic get
>>>> caught immediately.
>>>
>>> Of course it is important to have good test regimes in place - noting
>>> again that everyone involved is human and tests are never perfect. In
>>> particular, testing can never prove the absence of bugs, but only prove
>>> their presence.
>>
>> But in the case in point there is a bug! People do write silly things
>> like putting code next to branch of an if whilst forgetting to add the
>> {}s. But the result is code with a bug that will be found in the very
>> first test run. This is either a non-issue (as I hope it would be in
>> most production environments), or it signals that something else is
>> seriously wrong.
>
> How many programs are written with /complete/ test coverage? I expect
> that if you round to the nearest tenth of a percent, the answer is 0%.
No wonder the profession is in crisis. So much time posting about {}s
and so little about untested code. (I have to take your numbers at face
value -- I have no data at all.)
> This kind of thing has caused bugs that escaped into the wild - in
> code that was reviewed, heavily tested, and used massively in large
> numbers of systems.
This kind of assertion is unhelpful without details. There's no way to
determine what really went wrong and what process or procedure would
have prevented it.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-02-09 13:01 +0100 |
| Message-ID | <r1osb3$4a5$1@dont-email.me> |
| In reply to | #149876 |
On 09/02/2020 03:07, Ben Bacarisse wrote:
> This exchange is, I feel, not very productive. You seem to be
> attributing to me views I don't have and arguing against those.
>
> In particular, you seem to think I don't value "clarity" in code and,
> secondarily, that I think code is for computers not humans. I don't
> know how you got that from what I wrote. Maybe I was not clear.
>
> Anyway, I'm going to reply to only a couple of very specific points
> because I am not against writing clear code.
I don't think you gave the impression of being against writing clear
code, and I am sorry if it looked as though I thought that.
I think merely that we have different opinions as to what comprises
clear code, and perhaps different emphasis on the benefits of particular
details of code formatting choices.
And while we both prefer to write clear code (for different measures of
"clear"), we may also have different levels of dislike of unclear code.
>
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 08/02/2020 00:36, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 07/02/2020 02:26, Ben Bacarisse wrote:
>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>>
<snip>
>>>
>>
>> I know which "if" the "else" belonged to. But I don't think the
>> format of the code matches the semantics of the code, and I think that
>> is bad style - it risks confusion.
>
> What is the confusion that is risked? Do you mean thata there are at
> least two meanings that could be considered for the original code? If
> so, what are those? If not, what is the risk you see?
Looking back at the original code (this thread has got a bit too long),
I don't think I would have trouble understanding the meaning. But it
requires more mental effort than it should do in order to read the code.
And the point of the original post is that some people might well see
two possible meanings of it. Not all people reading C code are as
experienced as you or I.
Some of the later examples in the thread have had more scope for
confusion, where it is unclear whether the programmer meant one thing
and wrote semantically incorrect code, or meant to write what the C code
says, but did so with unclear formatting.
>
> <cut>
>>>>> What's more, you are suggesting that code errors of this sort frequently
>>>>> survive long enough for someone like you to see them. Whilst C programs
>>>>> can have subtle errors that go uncaught for some time, your people
>>>>> should have a testing regime in place so that basic errors of logic get
>>>>> caught immediately.
>>>>
>>>> Of course it is important to have good test regimes in place - noting
>>>> again that everyone involved is human and tests are never perfect. In
>>>> particular, testing can never prove the absence of bugs, but only prove
>>>> their presence.
>>>
>>> But in the case in point there is a bug! People do write silly things
>>> like putting code next to branch of an if whilst forgetting to add the
>>> {}s. But the result is code with a bug that will be found in the very
>>> first test run. This is either a non-issue (as I hope it would be in
>>> most production environments), or it signals that something else is
>>> seriously wrong.
>>
>> How many programs are written with /complete/ test coverage? I expect
>> that if you round to the nearest tenth of a percent, the answer is 0%.
>
> No wonder the profession is in crisis. So much time posting about {}s
> and so little about untested code. (I have to take your numbers at face
> value -- I have no data at all.)
I can't claim any references for the numbers either. I just know there
is a great deal of code gets released and used without complete test
coverage. Most of it gets tested reasonably, I expect. But how many
people who check the result of "malloc" for a null pointer return can
honestly say they always use fault injection to test the code path
followed on allocation error? (That is, of course, just one example.)
>
>> This kind of thing has caused bugs that escaped into the wild - in
>> code that was reviewed, heavily tested, and used massively in large
>> numbers of systems.
>
> This kind of assertion is unhelpful without details. There's no way to
> determine what really went wrong and what process or procedure would
> have prevented it.
>
A famous example would be the "Apple goto fail" in their SSL/TLS code.
I assume (perhaps inappropriately) that Apple tested this code, and it
was certainly commonly used code.
The relevant section of the code was
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
With a code formatting style that required braces on "if" statements,
that mistake would have stood out like a sore thumb.
(It could also have been found in other ways, of course, including
better static analysis, better testing, better reviews, etc.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-02-09 13:26 +0000 |
| Message-ID | <sMT%F.632617$Arx.343804@fx08.am4> |
| In reply to | #149878 |
On 09/02/2020 12:01, David Brown wrote:
> On 09/02/2020 03:07, Ben Bacarisse wrote:
>> This kind of assertion is unhelpful without details. There's no way to
>> determine what really went wrong and what process or procedure would
>> have prevented it.
>>
>
> A famous example would be the "Apple goto fail" in their SSL/TLS code. I
> assume (perhaps inappropriately) that Apple tested this code, and it was
> certainly commonly used code.
>
> The relevant section of the code was
>
> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
> goto fail;
> if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
> goto fail;
> goto fail;
> if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
> goto fail;
>
> With a code formatting style that required braces on "if" statements,
> that mistake would have stood out like a sore thumb.
>
> (It could also have been found in other ways, of course, including
> better static analysis, better testing, better reviews, etc.)
>
The problem with guidelines is that they can't really be enforced.
Suppose someone forgets braces somewhere in 10s of 1000s of lines of
code - it can't be detected.
Better the compiler enforces it (since the language cannot do so). I
tried this in my C compiler and it took about 6 minutes to enforce {...}
blocks for if, while, do, for and switch statements.
(That's with an option for it set within the code - say 10 minutes in
all for a user-settable option.)
10 minutes' work for something that could potentially have saved untold
numbers of bugs, debugging time, and lurking bugs that could still exist.
Of course this can't be used for existing code as little of it will pass
(except funnily enough my generated code). It's only practical for new code.
Does gcc have such an option? There was nothing immediately obvious.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-09 15:53 +0000 |
| Message-ID | <87r1z3lpti.fsf@bsb.me.uk> |
| In reply to | #149880 |
Bart <bc@freeuk.com> writes: > On 09/02/2020 12:01, David Brown wrote: >> On 09/02/2020 03:07, Ben Bacarisse wrote: > >>> This kind of assertion is unhelpful without details. There's no way to >>> determine what really went wrong and what process or procedure would >>> have prevented it. >>> >> >> A famous example would be the "Apple goto fail" in their SSL/TLS code. I assume (perhaps inappropriately) that Apple tested this code, and it was certainly commonly used code. >> >> The relevant section of the code was >> >> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) >> goto fail; >> if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) >> goto fail; >> goto fail; >> if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) >> goto fail; >> >> With a code formatting style that required braces on "if" statements, that mistake would have stood out like a sore thumb. >> >> (It could also have been found in other ways, of course, including better static analysis, better testing, better reviews, etc.) >> > > The problem with guidelines is that they can't really be > enforced. Suppose someone forgets braces somewhere in 10s of 1000s of > lines of code - it can't be detected. Of course it can. You even say how it can be detected: > Better the compiler enforces it [...] Though there are other ways. There used to be programs than parsed C an reported on style failures (as well as doing some more serious static analysis). Lint was one such rather simplistic example. They probably still exist. > Does gcc have such an option? There was nothing immediately obvious. I could not see any either, but it could do it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-02-09 17:03 +0100 |
| Message-ID | <r1pahg$o9i$1@dont-email.me> |
| In reply to | #149880 |
On 09/02/2020 14:26, Bart wrote:
> On 09/02/2020 12:01, David Brown wrote:
>> On 09/02/2020 03:07, Ben Bacarisse wrote:
>
>>> This kind of assertion is unhelpful without details. There's no way to
>>> determine what really went wrong and what process or procedure would
>>> have prevented it.
>>>
>>
>> A famous example would be the "Apple goto fail" in their SSL/TLS code.
>> I assume (perhaps inappropriately) that Apple tested this code, and it
>> was certainly commonly used code.
>>
>> The relevant section of the code was
>>
>> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
>> goto fail;
>> if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
>> goto fail;
>> goto fail;
>> if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
>> goto fail;
>>
>> With a code formatting style that required braces on "if" statements,
>> that mistake would have stood out like a sore thumb.
>>
>> (It could also have been found in other ways, of course, including
>> better static analysis, better testing, better reviews, etc.)
>>
>
> The problem with guidelines is that they can't really be enforced.
> Suppose someone forgets braces somewhere in 10s of 1000s of lines of
> code - it can't be detected.
That depends on the guidelines - some most certainly /can/ be detected
automatically, and therefore easily enforced. Others cannot.
>
> Better the compiler enforces it (since the language cannot do so). I
> tried this in my C compiler and it took about 6 minutes to enforce {...}
> blocks for if, while, do, for and switch statements.
It would not be difficult to make the braces a requirement. It's a lot
more difficult if you accept certain exceptions.
>
> (That's with an option for it set within the code - say 10 minutes in
> all for a user-settable option.)
>
> 10 minutes' work for something that could potentially have saved untold
> numbers of bugs, debugging time, and lurking bugs that could still exist.
>
> Of course this can't be used for existing code as little of it will pass
> (except funnily enough my generated code). It's only practical for new
> code.
>
> Does gcc have such an option? There was nothing immediately obvious.
It has "-Wmisleading-indentation", which will catch many of the worst
offences, but does not enforce braces.
Another possibility is to use one of the many C "beautifiers" or
"styliser" programs that exist which re-arrange C code to match your
particular style choices. You could easily arrange for your build
system to pass your code through such a program then compare the output
to the original - if there are differences, the original code is not in
the required style. (Yes, that's an inconvenient extra step or two, but
certainly achievable if you want it.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-09 15:35 +0000 |
| Message-ID | <87zhdrlqns.fsf@bsb.me.uk> |
| In reply to | #149878 |
David Brown <david.brown@hesbynett.no> writes:
> On 09/02/2020 03:07, Ben Bacarisse wrote:
>> This exchange is, I feel, not very productive. You seem to be
>> attributing to me views I don't have and arguing against those.
>>
>> In particular, you seem to think I don't value "clarity" in code and,
>> secondarily, that I think code is for computers not humans. I don't
>> know how you got that from what I wrote. Maybe I was not clear.
>>
>> Anyway, I'm going to reply to only a couple of very specific points
>> because I am not against writing clear code.
>
> I don't think you gave the impression of being against writing clear
> code, and I am sorry if it looked as though I thought that.
>
> I think merely that we have different opinions as to what comprises
> clear code, and perhaps different emphasis on the benefits of
> particular details of code formatting choices.
>
> And while we both prefer to write clear code (for different measures
>of "clear"), we may also have different levels of dislike of unclear
>code.
>
>
>>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 08/02/2020 00:36, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 07/02/2020 02:26, Ben Bacarisse wrote:
>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>>>
> <snip>
>>>>
>>>
>>> I know which "if" the "else" belonged to. But I don't think the
>>> format of the code matches the semantics of the code, and I think that
>>> is bad style - it risks confusion.
>>
>> What is the confusion that is risked? Do you mean thata there are at
>> least two meanings that could be considered for the original code? If
>> so, what are those? If not, what is the risk you see?
>
> Looking back at the original code (this thread has got a bit too
> long), I don't think I would have trouble understanding the meaning.
> But it requires more mental effort than it should do in order to read
> the code. And the point of the original post is that some people might
> well see two possible meanings of it. Not all people reading C code
> are as experienced as you or I.
This is where it gets so frustrating. Who are these people who can give
that code more than one totally obvious meaning, and why are they even
reading C much less possibly maintaining it? Have you ever met such a
person? Why were they reading C code? If you have come across such a
programmer, what is the other interpretation that they might consider?
I really want to understand other people's perspectives on this because
my imagination fails me here. I think I have a syntax-oriented brain.
Syntax errors (or formatting oddities like the one you show below) just
SCREAM AT ME and I react in an almost visceral way to them.
> Some of the later examples in the thread have had more scope for
> confusion, where it is unclear whether the programmer meant one thing
> and wrote semantically incorrect code, or meant to write what the C
> code says, but did so with unclear formatting.
I'll just note that I am much less interested in the intent of the
author than others seem to be. Of course the code should be clear, and
the formatting and layout should reflect the syntax (it can't really
reflect the intent unless the code is also correct) but I don't read
what I think the author meant, I read what the author wrote.
>> <cut>
>>>>>> What's more, you are suggesting that code errors of this sort frequently
>>>>>> survive long enough for someone like you to see them. Whilst C programs
>>>>>> can have subtle errors that go uncaught for some time, your people
>>>>>> should have a testing regime in place so that basic errors of logic get
>>>>>> caught immediately.
>>>>>
>>>>> Of course it is important to have good test regimes in place - noting
>>>>> again that everyone involved is human and tests are never perfect. In
>>>>> particular, testing can never prove the absence of bugs, but only prove
>>>>> their presence.
>>>>
>>>> But in the case in point there is a bug! People do write silly things
>>>> like putting code next to branch of an if whilst forgetting to add the
>>>> {}s. But the result is code with a bug that will be found in the very
>>>> first test run. This is either a non-issue (as I hope it would be in
>>>> most production environments), or it signals that something else is
>>>> seriously wrong.
>>>
>>> How many programs are written with /complete/ test coverage? I expect
>>> that if you round to the nearest tenth of a percent, the answer is 0%.
>>
>> No wonder the profession is in crisis. So much time posting about {}s
>> and so little about untested code. (I have to take your numbers at face
>> value -- I have no data at all.)
>
> I can't claim any references for the numbers either. I just know
> there is a great deal of code gets released and used without complete
> test coverage. Most of it gets tested reasonably, I expect. But how
> many people who check the result of "malloc" for a null pointer return
> can honestly say they always use fault injection to test the code path
> followed on allocation error? (That is, of course, just one example.)
Yes, and IO errors can be particularly hard. By the way, when I mean
tested I don't necessarily mean automatically tested with a test suite,
but I think programmers should test as much as possible even if that
involves using a debugger to force an error return from a library
function.
Anyway, as I said, I accept your depressing numbers. What is odd, in
the light of them, is how little talk there is here about testing code
compared to the relatively frequent debates about ()s and {}s.
>>> This kind of thing has caused bugs that escaped into the wild - in
>>> code that was reviewed, heavily tested, and used massively in large
>>> numbers of systems.
>>
>> This kind of assertion is unhelpful without details. There's no way to
>> determine what really went wrong and what process or procedure would
>> have prevented it.
>>
>
> A famous example would be the "Apple goto fail" in their SSL/TLS
> code. I assume (perhaps inappropriately) that Apple tested this code,
> and it was certainly commonly used code.
>
> The relevant section of the code was
>
> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
> goto fail;
> if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
> goto fail;
> goto fail;
> if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
> goto fail;
>
> With a code formatting style that required braces on "if" statements,
> that mistake would have stood out like a sore thumb.
Seriously? That mistake does not stand out like a sore thumb? I mean
that almost literally. Just a glance for a fraction of second and I am
almost in physical pain.
Anyway, if this is an example of what you meant, this code must have
been "heavily tested". Was it? A whole chunk of code has no test
coverage (the function continues, of course) even with no test harness
to simulate errors.
This is a classic example of why goto is considered harmful. The bug
comes from the fact that the fail label (presumably) just returns err.
Every place where you have
label:
<code>;
in a C function you must check (and test) every place from which you can
get here. That's why I hate gotos so much and why I am cautious about
breaks. The pre-conditions for "<code>" are hard to determine.
Of course, no one determines pre- and post-conditions these days and I
accept that that is now a lost art, but in my very limited experience,
I've found more bugs from simple and informal reasoning about code than
I ever found through testing.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-02-09 18:07 +0100 |
| Message-ID | <r1pe93$1cco$1@gioia.aioe.org> |
| In reply to | #149883 |
On 2/9/2020 4:35 PM, Ben Bacarisse wrote: > Of course, no one determines pre- and post-conditions these days and I > accept that that is now a lost art, If it is of any relief, that's not my experience. but in my very limited experience, > I've found more bugs from simple and informal reasoning about code than > I ever found through testing. On this side, I have found unit tests quite valuable instead, expecially when maintaining someone else's code.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-02-09 21:17 +0000 |
| Message-ID | <87ftfjlatj.fsf@bsb.me.uk> |
| In reply to | #149888 |
Manfred <noname@add.invalid> writes: > On 2/9/2020 4:35 PM, Ben Bacarisse wrote: >> Of course, no one determines pre- and post-conditions these days and I >> accept that that is now a lost art, > If it is of any relief, that's not my experience. Interesting. What field do you work in and is it mainly C code? (Feel free to ignore this question as I will understand if you prefer not to say.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-02-11 07:19 +0000 |
| Subject | Pre- and post- conditions (was Re: Coding style for small if statements) |
| Message-ID | <slrnr44lcg.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #149888 |
On Sun, 2020-02-09, Manfred wrote: > On 2/9/2020 4:35 PM, Ben Bacarisse wrote: >> Of course, no one determines pre- and post-conditions these days and I >> accept that that is now a lost art, > If it is of any relief, that's not my experience. > >> but in my very limited experience, I've found more bugs from simple >> and informal reasoning about code than I ever found through >> testing. Me too. The only way I know to understand code is in terms of preconditions and invariants. I never write it down though and I rarely speak about it. I assume everyone else does this too, but I cannot be sure. > On this side, I have found unit tests quite valuable instead, > expecially when maintaining someone else's code. The thing I have against unit tests is that, for me, writing tests means I don't read the code as carefully. If my tests pass, that means the code is free of bugs, right? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-02-10 23:40 -0800 |
| Subject | Re: Pre- and post- conditions (was Re: Coding style for small if statements) |
| Message-ID | <4175e33c-8892-4b9d-b08f-0cee4e0830a5@googlegroups.com> |
| In reply to | #149940 |
On Tuesday, 11 February 2020 09:19:54 UTC+2, Jorgen Grahn wrote: > On Sun, 2020-02-09, Manfred wrote: > > On 2/9/2020 4:35 PM, Ben Bacarisse wrote: > >> Of course, no one determines pre- and post-conditions these days and I > >> accept that that is now a lost art, > > > If it is of any relief, that's not my experience. > > > >> but in my very limited experience, I've found more bugs from simple > >> and informal reasoning about code than I ever found through > >> testing. > > Me too. The only way I know to understand code is in terms of > preconditions and invariants. I never write it down though and I > rarely speak about it. > > I assume everyone else does this too, but I cannot be sure. > > > On this side, I have found unit tests quite valuable instead, > > expecially when maintaining someone else's code. > > The thing I have against unit tests is that, for me, writing tests > means I don't read the code as carefully. If my tests pass, that > means the code is free of bugs, right? No, unit testing results with just somewhat less buggy programs with lower chance of breaking the logic with maintenance. Unit test is a very little program and so it usually takes lot less time to find out what precisely went wrong when it fails. Often it is obvious so there are no need to debug it.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web