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


Groups > comp.lang.c > #167917

Re: C naming conventions

From Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups comp.lang.c
Subject Re: C naming conventions
Date 2022-09-30 18:32 +0000
Organization A noiseless patient Spider
Message-ID <20220930110930.978@kylheku.com> (permalink)
References <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com> <th7avs$12mc7$1@dont-email.me>

Show all headers | View raw


On 2022-09-30, John Bode <jfbode1029@gmail.com> wrote:
> On 8/27/22 6:06 PM, Thiago Adams wrote:
>> I am searching for C naming conventions.
>> For instance, how to name structs, function, global variables...
>> 
>> Any link?  What are the "classic ones? "
>> 
>> I think one sample is "Win32" API
>
> All naming conventions suck.  All brace style conventions suck.  Anyone 
> can make good arguments for or against any convention you pick.
>
> The only things you really have to worry about are:
>
>   - Names beginning with "_" and "__" are reserved for the
>     implementation - don't use them in your code;
>
>   - Type names ending in "_t" reserved under POSIX - don't use it for
>     any user-defined types;

POSIX claiming _t means next to nothing.

They are just saying that POSIX will introduce new typedef names in this
space, which will steamroll any same named identifier of yours.

But! Historically, revisions of POSIX have not confined themselves to
previously documented namespaces.

In other words, the POSIX committee will run over any identifier
whatsoever that pops into their heads in the future, whether in
a previously reserved space or not.

You have to be prepared for a new version of POSIX to clash with
identifier in your program in any case, whether you use _t or not.

So pretty much it is safe to ignore it and use _t for your own
typedef names.

Suppose you are tryinjg to name a type and don't know whether to
choose asdfhjkl_t or asdfhjkl. 

The likelihood that POSIX will clash with asdfhjkl in the future
is *greater* than that it will clash with asdfhjkl_t, because
the former belongs to a more general, more populous namespace in which
names are created more frequently.

One thing you can do is try not to introduce typedef names in local
scopes, so then if a clash shows up, it will be a straight global
redefinition that is diagnosed --- as opposed to some macro hygiene
issue that might cause an undiagnosed problem.

Say that some POSIX macro references a _t typedef name. E.g. in a cast
expression or whatever. If you use that macro in a local scope in
which you also redefine that type locally, you have unwanted
capture: the macro expansion now refers to your own _t name, with
whatever consequences. The POSIX macro arguably then relies on the
reserved space for hygiene which you broke.

POSIX functions have the same problem anyway. Say POSIX introduces
some new function asdfjkl and has a macro whose expansion calls it.
You have a function argument asdfgjkl in the scoipe of that macro,
and that argument is a function pointer which can be called
with allt he same arguments!

   #define posix_macro do { ... asdfghkl(str) ... } while (0)

   void mycode(void (*asdfgjkl)(const char *), int other_arg)
   {
      posix_macro(other_arg); // oops
   }

Well written system headers prevent this by referring to aliases
in the __ namespace. A non-idiot implementor of POSIX will
have it like this:

   #define posix_macro do { ... __internal__asdfghkl(str) ... } while (0)

and that should be done for type names,  __foo_t and not foo_t,
regardless of the stupid _t namespace thing granted by the spec.

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

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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