Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #149567 > unrolled thread

Coding style for small if statements

Back to article view | Back to comp.lang.c

Contents

  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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#149912

On 10/02/2020 12:07, Bart wrote:
> On 10/02/2020 08:55, David Brown wrote:
>> On 10/02/2020 02:39, Ben Bacarisse wrote:
>>>
>>> Rather than mandate {}s all over the place, I would prefer to
>>> concentrate on the procedures for version control and testing.  But
>>> that's because I don't like visual clutter and I do like having reliable
>>> procedures.
>>>
>>
>> My preference is to use /both/, so that mistakes are less likely to be
>> missed.
>>
>> I don't like visual clutter either, but I don't see braces as visual
>> clutter - I see them as a simple and consistent way of arranging code
>> that works well with indentation.  But of course habit and familiarity
>> is a key part of what any one person finds "visual clutter".
>>
> 
> It /is/ extra clutter compared with some styles of block delimiting (as
> used in other languages not just C).
> 
> For example, having to write "} else {" instead of just "else" in
> patterns like this (exprs/statements not shown):
> 
>   if ( ) { } else { }        # C, 8 framing tokens
> 
>   if then else fi            # Algol68-inspired, 4 framing tokens
> 
> This is why it's tempting in C to just write:
> 
>   if ( ) else
> 
> when possible. It comes down to language design choices that were not
> the best.

The language design in C is consistent - the braces give you a way to
take a series of statements and declarations and make them into a single
compound statement.  This is a useful feature in a language, which can
then be re-used in many circumstances.

When you make different choices in a language design, you have different
tradeoffs.  If you have a language that makes it simple and convenient
to write things you want to write, it will also make it easy to
accidentally write things that you want to be illegal in the language.
If you make it tight enough to block more of the things you want to be
flagged as a mistake, it will make some things you want to write more
verbose.

You regularly claim C has bad design for things like this.  I don't see
it as a "bad" language, just that it allows some bad coding.  But /all/
languages allow bad coding.  No matter what the language, it is up to
users to impose additional restrictions on what they will accept as
"good" coding practices - with different users having different
requirements here.

I think your bias about languages comes from having written your own
languages.  You have made some languages that are heavily geared to
being a close match for how /you/ want to write code for the tasks /you/
need to solve.  You then think every other language is poorly designed
because it is not as perfect a match as the ones you designed.  But you
fail to consider that the world is bigger than /you/.  You can be
entirely confident that if anyone else were to use your language, they
would find faults, restrictions, limitations, and problems with it
because was designed for /you/, not for them.  And you can be entirely
confident that if anyone else were to use your language, they would
write code that you would find bad style, or write things that you would
have preferred to be illegal code but you simply didn't think about.

(Don't take this to mean I like all the design decisions of C - there's
lots I would prefer to be different.  But I understand that /my/ ideas
about what could be improved in C would be different from other people's
ideas, and if I want to enforce /my/ ways of writing a language then it
is up to /me/ to do so.)

[toc] | [prev] | [next] | [standalone]

#149914

On 10/02/2020 11:48, David Brown wrote:
> On 10/02/2020 12:07, Bart wrote:

>> It /is/ extra clutter compared with some styles of block delimiting (as
>> used in other languages not just C).
>>
>> For example, having to write "} else {" instead of just "else" in
>> patterns like this (exprs/statements not shown):
>>
>>    if ( ) { } else { }        # C, 8 framing tokens
>>
>>    if then else fi            # Algol68-inspired, 4 framing tokens
>>
>> This is why it's tempting in C to just write:
>>
>>    if ( ) else
>>
>> when possible. It comes down to language design choices that were not
>> the best.
> 
> The language design in C is consistent - the braces give you a way to
> take a series of statements and declarations and make them into a single
> compound statement.  This is a useful feature in a language, which can
> then be re-used in many circumstances.

You'd have to explain to me why that is useful. (My own Algol68-derived 
syntax doesn't need to do that.)

Here's another non-C example for my pattern:

    if then begin end else begin end

which has the same problems as C braces, but looks even worse. I believe 
this was Algol60/Pascal style, which also, like C, allows a 
single-statement form:

    if then else

begin-end being optional means it suffers from the issues as {} being 
optional.

> 
> When you make different choices in a language design, you have different
> tradeoffs.  If you have a language that makes it simple and convenient
> to write things you want to write, it will also make it easy to
> accidentally write things that you want to be illegal in the language.
> If you make it tight enough to block more of the things you want to be
> flagged as a mistake, it will make some things you want to write more
> verbose.
> 
> You regularly claim C has bad design for things like this.

See above. C doesn't have a monopoly on bad choices made decades ago.

> I think your bias about languages comes from having written your own
> languages.

With syntax 'inspired' by Algol68, despite never having used that 
language. Because I could see that it used the Right approach to dealing 
with block delimiting.

However, there are many differences because there are aspects of Algol68 
I didn't like. For example, a function body is a single statement (a 
'unit', which is also an expression) in Algol68, so you need begin...end 
(or (...) to wrap most functions' bodies.

This one C actually got right (compound statements are mandatory for 
function bodies).

> You have made some languages that are heavily geared to
> being a close match for how /you/ want to write code for the tasks /you/
> need to solve.  You then think every other language is poorly designed
> because it is not as perfect a match as the ones you designed.  But you
> fail to consider that the world is bigger than /you/.  You can be
> entirely confident that if anyone else were to use your language, they
> would find faults, restrictions, limitations, and problems with it
> because was designed for /you/, not for them.

No, the block delimiting style I prefer, while it started with Algol68, 
is also used by, for example:

     Ada
     Modern Fortran
     Lua
     The C preprocessor
     Bash

It's not a private thing.

[toc] | [prev] | [next] | [standalone]

#149916

On 10/02/2020 14:13, Bart wrote:
> On 10/02/2020 11:48, David Brown wrote:
>> On 10/02/2020 12:07, Bart wrote:
> 
>>> It /is/ extra clutter compared with some styles of block delimiting (as
>>> used in other languages not just C).
>>>
>>> For example, having to write "} else {" instead of just "else" in
>>> patterns like this (exprs/statements not shown):
>>>
>>>    if ( ) { } else { }        # C, 8 framing tokens
>>>
>>>    if then else fi            # Algol68-inspired, 4 framing tokens
>>>
>>> This is why it's tempting in C to just write:
>>>
>>>    if ( ) else
>>>
>>> when possible. It comes down to language design choices that were not
>>> the best.
>>
>> The language design in C is consistent - the braces give you a way to
>> take a series of statements and declarations and make them into a single
>> compound statement.  This is a useful feature in a language, which can
>> then be re-used in many circumstances.
> 
> You'd have to explain to me why that is useful. (My own Algol68-derived
> syntax doesn't need to do that.)

It is useful for being able to have small-scope local variables.  (I
have tried to explain to you in the past why that is a useful thing, but
it has never sunk in.  Please just accept that other people like to have
small scopes even if you don't.)  And it means that in the language,
lots of features can be made based on a "statement", and the user can
decide if they want a compound statement or not.  Thus conditionals have
the grammar:

	if (expression) statement

That lets people write:

	if (!ok) return;

as well as

	if (ok) {
		do_something();
	}

and :

	if (ok)
		do_something();


> 
> Here's another non-C example for my pattern:
> 
>    if then begin end else begin end
> 
> which has the same problems as C braces, but looks even worse. I believe
> this was Algol60/Pascal style, which also, like C, allows a
> single-statement form:
> 
>    if then else
> 
> begin-end being optional means it suffers from the issues as {} being
> optional.
> 
>>
>> When you make different choices in a language design, you have different
>> tradeoffs.  If you have a language that makes it simple and convenient
>> to write things you want to write, it will also make it easy to
>> accidentally write things that you want to be illegal in the language.
>> If you make it tight enough to block more of the things you want to be
>> flagged as a mistake, it will make some things you want to write more
>> verbose.
>>
>> You regularly claim C has bad design for things like this.
> 
> See above. C doesn't have a monopoly on bad choices made decades ago.

But /you/ have a monopoly on deciding whether a choice was bad or not?

> 
>> I think your bias about languages comes from having written your own
>> languages.
> 
> With syntax 'inspired' by Algol68, despite never having used that
> language. Because I could see that it used the Right approach to dealing
> with block delimiting.
> 
> However, there are many differences because there are aspects of Algol68
> I didn't like. For example, a function body is a single statement (a
> 'unit', which is also an expression) in Algol68, so you need begin...end
> (or (...) to wrap most functions' bodies.
> 
> This one C actually got right (compound statements are mandatory for
> function bodies).
> 
>> You have made some languages that are heavily geared to
>> being a close match for how /you/ want to write code for the tasks /you/
>> need to solve.  You then think every other language is poorly designed
>> because it is not as perfect a match as the ones you designed.  But you
>> fail to consider that the world is bigger than /you/.  You can be
>> entirely confident that if anyone else were to use your language, they
>> would find faults, restrictions, limitations, and problems with it
>> because was designed for /you/, not for them.
> 
> No, the block delimiting style I prefer, while it started with Algol68,
> is also used by, for example:
> 
>     Ada
>     Modern Fortran
>     Lua
>     The C preprocessor
>     Bash
> 
> It's not a private thing.
> 

Your language /is/ a private thing, even though many aspects may be
similar or identical to aspects of other languages.

[toc] | [prev] | [next] | [standalone]

#149920

David Brown <david.brown@hesbynett.no> writes:

> On 10/02/2020 12:07, Bart wrote:
>> On 10/02/2020 08:55, David Brown wrote:
>>> On 10/02/2020 02:39, Ben Bacarisse wrote:
>>>>
>>>> Rather than mandate {}s all over the place, I would prefer to
>>>> concentrate on the procedures for version control and testing.  But
>>>> that's because I don't like visual clutter and I do like having reliable
>>>> procedures.
>>>>
>>>
>>> My preference is to use /both/, so that mistakes are less likely to be
>>> missed.
>>>
>>> I don't like visual clutter either, but I don't see braces as visual
>>> clutter - I see them as a simple and consistent way of arranging code
>>> that works well with indentation.  But of course habit and familiarity
>>> is a key part of what any one person finds "visual clutter".
>>>
>> 
>> It /is/ extra clutter compared with some styles of block delimiting (as
>> used in other languages not just C).
>> 
>> For example, having to write "} else {" instead of just "else" in
>> patterns like this (exprs/statements not shown):
>> 
>>   if ( ) { } else { }        # C, 8 framing tokens
>> 
>>   if then else fi            # Algol68-inspired, 4 framing tokens
>> 
>> This is why it's tempting in C to just write:
>> 
>>   if ( ) else
>> 
>> when possible. It comes down to language design choices that were not
>> the best.
>
> The language design in C is consistent - the braces give you a way to
> take a series of statements and declarations and make them into a single
> compound statement.  This is a useful feature in a language, which can
> then be re-used in many circumstances.

This is not in doubt.  What being questioned is the fact that you have
to use the.  Algol 68 has begin and end but you don't often need them.

> When you make different choices in a language design, you have different
> tradeoffs.  If you have a language that makes it simple and convenient
> to write things you want to write, it will also make it easy to
> accidentally write things that you want to be illegal in the language.

I don't get this at all.  C makes requires you to all {}s to prevent the
kind fo accidents you seem to think are worth preventing.  They can't
happen in a language that closes ifs and loops and you don't need to add
begin and end.

> If you make it tight enough to block more of the things you want to be
> flagged as a mistake, it will make some things you want to write more
> verbose.

Again, I'm lost.  Maybe you could give an example.  Is, say,

  if C1 then S1 elif C2 then S2 else s3 fi

tight enough to block the things you want flagged as mistakes?  If so,
what things are more verbose?  In C, with your insistence on {}s to
prevent mistakes, this becomes

  if ( C1 ) { S1 } else { if ( C2 ) { S2 } else { S3 } }

> You regularly claim C has bad design for things like this.  I don't see
> it as a "bad" language, just that it allows some bad coding.  But /all/
> languages allow bad coding.

But the odd thing here is that you've been arguing about adding {}s to
prevent some mistakes where many languages simply can't have those
mistakes.  They don't need the programmer to follow rules about adding
syntactically redundant elements.  Languages like Algol 68 and Ada were
designed with exactly your concerns in mind.  Do they really not meet
your concerns?

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149906

On Sunday, February 9, 2020 at 5:52:21 PM UTC-5, Bart wrote:
> On 09/02/2020 21:50, Ben Bacarisse wrote:
...
> > If it was heavily tested and properly reviewed, those procedures need to
> > be looked at!
> 
> Maybe it was tested, but the line accidentally got duplicated 
> afterwards.

The only tests that matter are the ones that were done after the last time that the code was modified.

[toc] | [prev] | [next] | [standalone]

#149909

On 09/02/2020 22:50, Ben Bacarisse wrote:
> Again, forgive me for picking only one point to address...

You're forgiven.  Actually, you are thanked, for limiting and focusing
the thread.

> 
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 09/02/2020 16:35, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 09/02/2020 03:07, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>>>>>> 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.
>>
>> It stands out to me too.  But obviously it did not stand out to the
>> person who wrote it, or to the people responsible for reviewing it.
> 
> Well my point is that I don't really know what happened so I don't know
> how good an example it is.

I don't know either, I can only guess.

> 
> I am pretty sure that someone just "yanked" that line twice rather than
> once (that's the Emacs term -- other editors are available) and my guess
> is that the code never got more than the most perfunctory test and that
> it was not reviewed at all.
> 
> If it was heavily tested and properly reviewed, those procedures need to
> be looked at!
> 

Agreed.

But I have little doubt that bugs do escape to the wild that could have
been stopped by strict rules on code formatting, code layout, brace
style, and other rules that restrict the flexibility of coding (not just
in C - in other languages too).  As I noted, they could also have been
stopped by other layers in the development process.  It's just that
rules here are a cheap and easy layer, which is why I think they are
worth using.


Here's another speculative thought.  If you were to ask a random
selection of software developers about how they judged their testing,
reviewing and other development processes compared to others, what do
you think the answer would be?  I think (from gut feeling and
experience, not statistics, studies or reports) that most will answer
that they know they could be better and that they are not at the
standard you'd want for an automatic pilot, but they are a good deal
better than average for comparable businesses.  People are often
extremely poor at judging themselves like this.  (In real studies, some
90% of drivers say they think they are above-average drivers.)

[toc] | [prev] | [next] | [standalone]

#149917

David Brown <david.brown@hesbynett.no> writes:

> On 09/02/2020 22:50, Ben Bacarisse wrote:
<cut>
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 09/02/2020 16:35, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 09/02/2020 03:07, Ben Bacarisse wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>>>>>> 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.
>>>
>>> It stands out to me too.  But obviously it did not stand out to the
>>> person who wrote it, or to the people responsible for reviewing it.
>> 
>> Well my point is that I don't really know what happened so I don't know
>> how good an example it is.
>
> I don't know either, I can only guess.
>
>> I am pretty sure that someone just "yanked" that line twice rather than
>> once (that's the Emacs term -- other editors are available) and my guess
>> is that the code never got more than the most perfunctory test and that
>> it was not reviewed at all.
>> 
>> If it was heavily tested and properly reviewed, those procedures need to
>> be looked at!
>
> Agreed.
>
> But I have little doubt that bugs do escape to the wild that could have
> been stopped by strict rules on code formatting, code layout, brace
> style, and other rules that restrict the flexibility of coding (not just
> in C - in other languages too).

Well then, we agree.  I know that some bug like this escape into the
wild.  I objected to your claim that they escaped despite heavy testing
and code review.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149923

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Well then, we agree.  I know that some bug like this escape into the
>>wild.  I objected to your claim that they escaped despite heavy testing
>>and code review.
>
>   For an entertaining read - but you guys might already know this:
>
> www fastcompany com/28121/they-write-right-stuff
>
>   (two spaces need to be replaced by dots before using this address).

Why?  You are not making the link tempting to follow (which might, I
suppose, be your intent).  I prefer (a) a clickable link, (b) a brief
summary of what it at the link.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149892

On 09/02/2020 15:35, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:

>>      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.

This one does stand out, partly because it's two successive gotos, 
partly because it has already been isolated and therefore highlighted, 
complete with a comment that there is a mistake in that fragment of code!

Very frequently I have to debug other people's code by inserting print 
statements, often at the start of the branch of if-statements written 
like this:

     if (cond)
         stmt;

which then end up looking like:

     if (cond)
         printf("%d\n",__LINE__);
         stmt;

In the context of a real example which is going to be much busier and 
inside a large complex module, I find that an easy mistake to make (the 
mistake being the assumption that 'stmt' is bounded by braces). I expect 
many do as well, and with permanent code not my less serious temporary 
statement.



> 
> 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.

I thought compilers like the ones David uses would tell you that the 
statement after the unconditional goto was unreachable.

> 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.

I found that being confident about the overall picture, plan or scheme 
also leads to a good chance of it being correct. Localised logic errors 
are at a different level.

Where it starts getting murky, or I am not sure how something works, 
then it's time to revise or rewrite, or at least document, which 
requires setting things out.

[toc] | [prev] | [next] | [standalone]

#149895

Bart <bc@freeuk.com> writes:

> On 09/02/2020 15:35, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>>>      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;
<cut>
>> 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.
>
> I thought compilers like the ones David uses would tell you that the
> statement after the unconditional goto was unreachable.

Yes, but since he already mentioned that better tools could have spotted
the error I did not think it needed to be mentioned again.

But in the part you appeared to be replying to I was making a general
point about labels and why I dislike gotos: at the label you have to
assemble a complex picture of the program's state at all the points you
could have come to it from.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149902

On Sunday, February 9, 2020 at 3:29:26 PM UTC-6, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
> > On 09/02/2020 15:35, Ben Bacarisse wrote:
> >> David Brown <david.brown@hesbynett.no> writes:
> >
> >>>      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;
> <cut>
> >> 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.
> >
> > I thought compilers like the ones David uses would tell you that the
> > statement after the unconditional goto was unreachable.
> 
> Yes, but since he already mentioned that better tools could have spotted
> the error I did not think it needed to be mentioned again.
> 
> But in the part you appeared to be replying to I was making a general
> point about labels and why I dislike gotos: at the label you have to
> assemble a complex picture of the program's state at all the points you
> could have come to it from.
> 

INTERCAL to the rescue! lol

[toc] | [prev] | [next] | [standalone]

#149893

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>I'll just note that I am much less interested in the intent of the
>>author than others seem to be. 
>
>   The reason we ("others") are interested so much in the
>   intent of the author is that when proofreading code (also
>   known as "reviewing code") we want to /compare/ the intent
>   of the author with what he actually wrote in order to find
>   semantic errors.

There a problem here to do with the words.  I'm not sure what you mean
when you speak of "the intent of the author".  If you mean the fact that
the author intended to implement the specification, then of course I
care about that.  But that is not manifest in code.  It is manifest in
the specification.

>   We cannot get the intend from code, though.
>
>   Therefore we are grateful when the author has added unit
>   documentation, e.g., a function documentation comment
>   preceding the actual function. This documentation should
>   give in plain English what the intent of the author is,
>   and possibly even his motivation (why does he need such
>   a function?). If he also has written tests, the better!
>
>   Then we can compare his intent with his code.

If I understand you, yes, /that/ meaning of intent I do care about.  But
that was not the meaning being discussed, as can be seen from the fact
that no code with any overall specification has been presented.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149901

On 2/9/20 4:15 PM, Ben Bacarisse wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> I'll just note that I am much less interested in the intent of the
>>> author than others seem to be. 
>>
>>   The reason we ("others") are interested so much in the
>>   intent of the author is that when proofreading code (also
>>   known as "reviewing code") we want to /compare/ the intent
>>   of the author with what he actually wrote in order to find
>>   semantic errors.
> 
> There a problem here to do with the words.  I'm not sure what you mean
> when you speak of "the intent of the author".  If you mean the fact that
> the author intended to implement the specification, then of course I
> care about that.  But that is not manifest in code.  It is manifest in
> the specification.

The point under discussion was the fact that code itself often contains
hints (such as indentation levels) that the author's intent differed
from the way the code was actually written.

>>   We cannot get the intend from code, though.
>>
>>   Therefore we are grateful when the author has added unit
>>   documentation, e.g., a function documentation comment
>>   preceding the actual function. This documentation should
>>   give in plain English what the intent of the author is,
>>   and possibly even his motivation (why does he need such
>>   a function?). If he also has written tests, the better!
>>
>>   Then we can compare his intent with his code.
> 
> If I understand you, yes, /that/ meaning of intent I do care about.  But
> that was not the meaning being discussed, as can be seen from the fact
> that no code with any overall specification has been presented.

The intent was being inferred (and IMHO, reasonably so) from indications
in the code.

[toc] | [prev] | [next] | [standalone]

#149903

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 2/9/20 4:15 PM, Ben Bacarisse wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> 
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> I'll just note that I am much less interested in the intent of the
>>>> author than others seem to be. 
>>>
>>>   The reason we ("others") are interested so much in the
>>>   intent of the author is that when proofreading code (also
>>>   known as "reviewing code") we want to /compare/ the intent
>>>   of the author with what he actually wrote in order to find
>>>   semantic errors.
>> 
>> There a problem here to do with the words.  I'm not sure what you mean
>> when you speak of "the intent of the author".  If you mean the fact that
>> the author intended to implement the specification, then of course I
>> care about that.  But that is not manifest in code.  It is manifest in
>> the specification.
>
> The point under discussion was the fact that code itself often contains
> hints (such as indentation levels) that the author's intent differed
> from the way the code was actually written.

Yes, I got that.  That's kind of intent I am usually not interested in.

>>>   We cannot get the intend from code, though.
>>>
>>>   Therefore we are grateful when the author has added unit
>>>   documentation, e.g., a function documentation comment
>>>   preceding the actual function. This documentation should
>>>   give in plain English what the intent of the author is,
>>>   and possibly even his motivation (why does he need such
>>>   a function?). If he also has written tests, the better!
>>>
>>>   Then we can compare his intent with his code.
>> 
>> If I understand you, yes, /that/ meaning of intent I do care about.  But
>> that was not the meaning being discussed, as can be seen from the fact
>> that no code with any overall specification has been presented.
>
> The intent was being inferred (and IMHO, reasonably so) from indications
> in the code.

Yes, I know that making that sort of inference was being suggested.
I've not found it useful.  I can't think what I'd do with that
information.  How does it help to infer (unreliably) that the author
wrote correct code but intended to write incorrect code, or conversely,
that they intended to write incorrect code but happened to get it right?
What matters is what was written.

I agree that the presence of these signs might be a useful warning --
look carefully here because the indentation is all over the place -- but
that's not really inferring anything.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150140

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>> [...]
>
> Yes, I know that making that sort of inference was being
> suggested.  I've not found it useful.  I can't think what I'd do
> with that information.  How does it help to infer (unreliably)
> that the author wrote correct code but intended to write incorrect
> code, or conversely, that they intended to write incorrect code
> but happened to get it right?  What matters is what was written.
> [...]

I have found this conversation interesting but confusing.  I have a
few comments I would like to share, in reaction to the discussion
generally, and I guess here is as good a place as any.

When I read code I want to know more than just what is being done.
I look for what might be called a narrative, to understand the
reasoning of what's going on, in addition to the nuts and bolts of
how it gets done.  Ideally the code will convey a narrative closely
along the lines of what the author was thinking.  However I would
not call this intent necessarily.  Whether I discover or somehow
reconstruct the author's thoughts, or construct anew a narrative
independent of those thoughts, having a narrative is something
important for my reading and understanding.

Invariants are an essential tool, of course.  OTOH they aren't
always present in my thinking when I am writing, or reading,
code.  I'm not sure even what all the tools are that I use to
produce and confirm code that is correct.  Testing is one of
those tools, naturally.  Another tool is what I might call
"signposts", which are logical statements known or believed or
shown to be true, usually at a particular point of execution.
These aren't the same as invariants because they might, for
example, apply down only one branch of an if/else.  Still they
can help simplify the reasoning process.  A key point is that I
use different reasoning modes at different times, and never all
at once, but normally at most one or two at a time.  Part of why
it is hard to describe or discuss them is because I'm not always
conscious of what mental tools I'm using at any given time, let
alone over all times.

So fwiw there are some of my thoughts.  Please note that I am not
suggesting that tools I find useful are ones that others should
use.  Part of the problem with topics like this is they turn from
discussion into argument, with more emphasis on convincing than
on simply stating and explaining.  I would rather avoid the
convincing/arguing mode if possible.

[toc] | [prev] | [next] | [standalone]

#150047

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.  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.

Remarkable.  Advocating for a way of writing that uses eleven
lines where a single line suffices.

> Always write code assuming the person maintaining it is a violent
> psychopath who knows where you live.

If that were actually true you would already be dead, or at least
maimed severely. :)

[toc] | [prev] | [next] | [standalone]

#150049

On 16/02/2020 13:43, Tim Rentsch wrote:
> John Bode <jfbode1029@gmail.com> writes:

>> 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.
> 
> Remarkable.  Advocating for a way of writing that uses eleven
> lines where a single line suffices.

Five lines of code and 6 lines each containing a single brace.

Despite this, this is only 50% longer than your one-liner: 75 versus 50 
non-space characters.

My prefered brace style would make this 8 lines, and keeps the benefit 
of easier maintenance and easier insertion of extra statements.

[toc] | [prev] | [next] | [standalone]

#150151

Bart <bc@freeuk.com> writes:

> On 16/02/2020 13:43, Tim Rentsch wrote:
>
>> John Bode <jfbode1029@gmail.com> writes:
>>
>>> 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.
>>
>> Remarkable.  Advocating for a way of writing that uses eleven
>> lines where a single line suffices.
>
> Five lines of code and 6 lines each containing a single brace.
>
> Despite this, this is only 50% longer than your one-liner: 75 versus
> 50 non-space characters.

A silly comparison.  More lines always makes a program longer.
More characters do not, in most cases, make a program wider.

> My prefered brace style would make this 8 lines, and keeps the benefit
> of easier maintenance and easier insertion of extra statements.

If we factor in the low probability of needing to take advantage
of that flexibility, and add in the cost of extra program length
and reading time, the resulting ROI is net negative.  It's always
important to look at both sides of the scale.

[toc] | [prev] | [next] | [standalone]

#149821

Le 31/01/2020 à 21:46, Anton Shepelev a écrit :
> 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;

I never nest if's without adding braces, and never put the "then" or 
"else" clause on the same line. Both can be confusing to read 
(especially the former) and lead to bugs when maintaining the code.

> The criticism I received is that the reader may not eaily
> decide whether the author meant
> 
>                 if (dblh != dblw) {
>                    if (dblh)
>                       gfx_flags |= GFX_DBL_H;
>                 } else {
>                    gfx_flags |= GFX_DBL_W;
>                 }

Small digression:
Not to trigger a flamewar here, I know this is a topic for potentially 
heated debate here (coding style almost always is), but I personally 
just hate the opening braces at the end of lines. This style has become 
pervasive. I think it initially comes from the Kernighan & Richie style, 
which granted were the authors of C, but we have to keep in mind that in 
the 70's, screen estate was really at a premium, so it saved extra 
lines. These days, it's not really justified anymore and it just makes 
it look like block delimiters are an annoyance rather than a feature - I 
for one just don't agree with this point. And I like to keep my things 
aligned. End of digression anyway - there really seems to be two camps 
there with pretty aggressive positions.

But other than the location of opening braces - to me -, the above piece 
of code is much better than your first example, hands down.

[toc] | [prev] | [next] | [standalone]

#149823

On Friday, 7 February 2020 14:25:28 UTC, Guillaume  wrote:
> 
> Small digression:
> Not to trigger a flamewar here, I know this is a topic for potentially 
> heated debate here (coding style almost always is), but I personally 
> just hate the opening braces at the end of lines. This style has become 
> pervasive. I think it initially comes from the Kernighan & Richie style, 
> which granted were the authors of C, but we have to keep in mind that in 
> the 70's, screen estate was really at a premium, so it saved extra 
> lines.
>
K and R were producing a printed book. In print, the matched brace with
the brace the only thing on the line style looks typographically odd, as
well as consuming paper.

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web