Re: C naming conventions

From	Kaz Kylheku <480-992-1380@kylheku.com>
Newsgroups	comp.lang.c
Subject	Re: C naming conventions
Date	2022-09-13 05:38 +0000
Organization	A noiseless patient Spider
Message-ID	<20220912223026.317@kylheku.com> (permalink)
References	<3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com> <tf5deq$3l26r$1@dont-email.me> <86edwgptqk.fsf@linuxsc.com> <tfousb$2gf7l$1@dont-email.me>

Show all headers | View raw

On 2022-09-13, Kent Dickey <kegs@provalid.com> wrote:
> In article <86edwgptqk.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>kegs@provalid.com (Kent Dickey) writes:
> [snip]
>>> All structs must be typedef'ed and the typedef name is an initial capital.
>>
>>I try to follow the rule that all (developer-chosen) type names
>>start with a capital letter, and no other names do.  (Preprocesor
>>symbols are treated separately.)
>>
>>
>>> All structs are created by STRUCT(Sample_structure) where STRUCT is:
>>>     #define STRUCT(a) typedef struct a ## _st a;  struct a ## _st
>>
>>It is a little bit safer if STRUCT(a) were defined
>>
>>  #define STRUCT(a) \
>>    struct a ## _st;  typedef struct a ## _st a;  struct a ## _st
>>
>>The reasons are somewhat esoteric.  But since the leading
>>declaration is hidden inside a macro, it seems better to use the
>>safer form.
>
> What are the reasons?  It's not obvious to me what it is, but I would
> guess it's some sort of namespace conflict you're trying to avoid.
>
> [big snip]
>
>>> All names use _ and not CamelCase.
>>
>>Generally using underscores is better than either CamelCase or
>>camelCase, for ergonomic reasons.  An exception is type names,
>>where for example TreeNode arguably reads better than Tree_node.
>>(The type-name exception tacitly assumes that type names are
>>limited to at most four or five words;  more than that runs
>>into readability problems.)
>
> Most structs are "File-related-prefix" and then "description".  So
> Serial_bufferinfo, Disk_params, etc.
> I cannot imagine using more than 3 words, just 2 words is pretty long.

Like that silly POSIX with its pthread_mutex_attr_t cruft and whatnot.

OK, we are in POSIX, so the "p" is redundant, right?

Mutexes are owned by threads; so the "thread" is redundant.

Just mutex_lock, mutex_timedwait, mutex_t, mutex_attr_t, ...

posix_spawn is another stupidity; at least shorten it to pspawn, if
you don't want to clash with someone's spawn identifier.

aio_read could have been named posix_asyncio_read, but someone
had the good sense to refrain.

On a tangentially related topic, I could never use these buggered
languages with hierarchical modules:

  com.asshole.vendor.shit.library.sys.io.print("up yours!")

Good grief, on what planet is anything of the sort a good idea.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Thread

C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-27 16:06 -0700
  Re: C naming conventions antispam@math.uni.wroc.pl - 2022-08-27 23:42 +0000
    Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:42 -0700
      Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-08-29 19:12 -0700
        Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 10:54 -0700
          Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-30 20:21 +0200
  Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 09:02 -0700
    Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-29 20:06 +0200
      Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 18:15 -0700
        Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 18:46 -0700
          Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:21 -0400
            Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-06 10:52 +0100
            Re: C naming conventions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-06 11:03 -0700
        Re: C naming conventions Opus <ifonly@youknew.org> - 2022-08-30 05:22 +0200
    Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 21:25 +0100
  Re: C naming conventions Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:38 +0300
    Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:37 -0700
      Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:30 +0100
        Re: C naming conventions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-08-31 14:50 +0000
          Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 14:57 +0000
            Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:44 -0700
          Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:36 -0700
            Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:54 +0100
          Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:50 +0100
            Re: C naming conventions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-08-31 17:14 +0000
              Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 10:21 -0700
      Re: C naming conventions Anton Shepelev <anton.txt@gmail.com> - 2022-09-05 23:31 +0300
      Re: C naming conventions Bart <bc@freeuk.com> - 2022-09-05 21:44 +0100
        Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-05 18:00 -0700
      Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-11 09:22 -0700
        Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 20:33 +0100
          Re: C naming conventions Thiago Adams <thiago.adams@gmail.com> - 2022-09-11 13:18 -0700
          Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-09-11 21:16 -0700
            Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 11:51 +0100
  Re: C naming conventions luser droog <luser.droog@gmail.com> - 2022-08-30 19:36 -0700
  Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-05 17:59 +0000
    Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 07:12 -0700
      Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-13 03:53 +0000
        Re: C naming conventions Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 05:38 +0000
          Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-09-13 13:30 +0000
        Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 05:18 -0700
          Re: C naming conventions kegs@provalid.com (Kent Dickey) - 2022-09-13 22:55 +0000
            Re: C naming conventions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-13 16:58 -0700
            Re: C naming conventions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 08:05 -0700
  Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:16 -0400
  Re: C naming conventions Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 19:31 +0200
    Re: C naming conventions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-12 00:45 -0700
  Re: C naming conventions Jonathan Harston <jgh@mdfs.net> - 2022-09-27 06:00 -0700
  Re: C naming conventions John Bode <jfbode1029@gmail.com> - 2022-09-30 13:02 -0500
    Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 18:32 +0000
      Re: C naming conventions scott@slp53.sl.home (Scott Lurndal) - 2022-10-01 16:26 +0000
    Re: C naming conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-01 00:54 +0100
      Re: C naming conventions Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-10-01 00:35 -0400
        Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-10-01 08:12 +0000
      Re: C naming conventions Kaz Kylheku <864-117-4973@kylheku.com> - 2022-10-01 08:11 +0000

csiph-web