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

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

C naming conventions

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

Contents

  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

Page 3 of 3 — ← Prev page 1 2 [3]

#167664

kegs@provalid.com (Kent Dickey) writes:

> In article <86edwgptqk.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> kegs@provalid.com (Kent Dickey) writes:

[..largely condensed..]

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

It's common to think of 'typedef struct some_tag SomeTypeName;'
as doing two things, namely, introducing a new structure tag, and
giving an alternate name to a struct type having that tag.  What
actually happens is not exactly that.  The point of putting in
the leading 'struct a ## _st;' is to ensure that a new tag is
introduced into the relevant scope, rather than possibly reusing
an existing structure tag defined in an outer scope.  Basically
the point of having 'struct a ## _st;' is to make sure that the
following 'typedef struct a ## _st a;' behaves the way people
expect it to behave, and not be blindsided by different behavior
when the structure tag accidentally matches a tag defined in an
outer scope.

>> [...]
>
> My rules are a pushback against needless abstraction.  [...]

Whether an abstraction is needless is a subjective question.  It
seems to me that (some of) the rules you proprose effectively
prevent any abstraction in some cases, whether it is "needless"
or not.

>> [...]
>
> I'm trying to put some protective pads on to avoid C's many
> pitfalls, and make it easy to browse code, even without complex
> tools. [...]

I'm not sure what kinds of tools you count as "complex tools".
Do you mean to avoid using any of the standard utilities that
were part of Unix 40+ years ago?  To me it seems silly to design
rules assuming such a primitive environment (that is, one where
the common Unix utilities of circa 1980 were not present).

One question for you:  looking over your own code, what would
you say is a rough distribution of function lengths?  What is the
range of lengths, what is the average length, what is the median
length?  If you can get exact numbers, so much the better, but
rough guesses (assuming they are informed guesses) are fine.

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

#167688

In article <86a673piw4.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>kegs@provalid.com (Kent Dickey) writes:
>
>> In article <86edwgptqk.fsf@linuxsc.com>,
>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>
>>> kegs@provalid.com (Kent Dickey) writes:
>
>[..largely condensed..]
>
>>>> 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.
>
>It's common to think of 'typedef struct some_tag SomeTypeName;'
>as doing two things, namely, introducing a new structure tag, and
>giving an alternate name to a struct type having that tag.  What
>actually happens is not exactly that.  The point of putting in
>the leading 'struct a ## _st;' is to ensure that a new tag is
>introduced into the relevant scope, rather than possibly reusing
>an existing structure tag defined in an outer scope.  Basically
>the point of having 'struct a ## _st;' is to make sure that the
>following 'typedef struct a ## _st a;' behaves the way people
>expect it to behave, and not be blindsided by different behavior
>when the structure tag accidentally matches a tag defined in an
>outer scope.

I always keep STRUCT() at top (file) scope, but I'll keep this in mind.

>>> [...]
>>
>> My rules are a pushback against needless abstraction.  [...]
>
>Whether an abstraction is needless is a subjective question.  It
>seems to me that (some of) the rules you proprose effectively
>prevent any abstraction in some cases, whether it is "needless"
>or not.
>
>>> [...]
>>
>> I'm trying to put some protective pads on to avoid C's many
>> pitfalls, and make it easy to browse code, even without complex
>> tools. [...]
>
>I'm not sure what kinds of tools you count as "complex tools".
>Do you mean to avoid using any of the standard utilities that
>were part of Unix 40+ years ago?  To me it seems silly to design
>rules assuming such a primitive environment (that is, one where
>the common Unix utilities of circa 1980 were not present).
>
>One question for you:  looking over your own code, what would
>you say is a rough distribution of function lengths?  What is the
>range of lengths, what is the average length, what is the median
>length?  If you can get exact numbers, so much the better, but
>rough guesses (assuming they are informed guesses) are fine.

Unix 1980's stuff is fine, but I don't want to rely on cscope, syntax
highlighting and other IDE stuff if I don't need it.

You can see code that mostly meets my style definitions at:
http://kegs.sourceforge.net/kegs.1.16.tar.gz (some was written almost 30
years ago and doesn't meet the style guidelines and I have not fixed all
the problems yet, mostly function and global variable naming issues).  All my
functions look like:

return_type
function_name(arguments here)
{
...
}

(Primarily to make [[ and ]] work in vi, but it also makes many code grep's
easier, the definition of serial_init is /^serial_init in vi).

So I can find the number of functions with:
grep '^}$' *.c | wc
and the total lines:
wc *.c

and I get 36747/756 = 48.6 lines per function (counting all overhead outside
the functions as well).  ts=8.

Kent

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

#167691

On 9/13/2022 3:55 PM, Kent Dickey wrote:
> In article <86a673piw4.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>> kegs@provalid.com (Kent Dickey) writes:
>>
>>> In article <86edwgptqk.fsf@linuxsc.com>,
>>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> kegs@provalid.com (Kent Dickey) writes:
>>
>> [..largely condensed..]
>>
>>>>> 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.
>>
>> It's common to think of 'typedef struct some_tag SomeTypeName;'
>> as doing two things, namely, introducing a new structure tag, and
>> giving an alternate name to a struct type having that tag.  What
>> actually happens is not exactly that.  The point of putting in
>> the leading 'struct a ## _st;' is to ensure that a new tag is
>> introduced into the relevant scope, rather than possibly reusing
>> an existing structure tag defined in an outer scope.  Basically
>> the point of having 'struct a ## _st;' is to make sure that the
>> following 'typedef struct a ## _st a;' behaves the way people
>> expect it to behave, and not be blindsided by different behavior
>> when the structure tag accidentally matches a tag defined in an
>> outer scope.
> 
> I always keep STRUCT() at top (file) scope, but I'll keep this in mind.
> 
>>>> [...]
>>>
>>> My rules are a pushback against needless abstraction.  [...]
>>
>> Whether an abstraction is needless is a subjective question.  It
>> seems to me that (some of) the rules you proprose effectively
>> prevent any abstraction in some cases, whether it is "needless"
>> or not.
>>
>>>> [...]
>>>
>>> I'm trying to put some protective pads on to avoid C's many
>>> pitfalls, and make it easy to browse code, even without complex
>>> tools. [...]
>>
>> I'm not sure what kinds of tools you count as "complex tools".
>> Do you mean to avoid using any of the standard utilities that
>> were part of Unix 40+ years ago?  To me it seems silly to design
>> rules assuming such a primitive environment (that is, one where
>> the common Unix utilities of circa 1980 were not present).
>>
>> One question for you:  looking over your own code, what would
>> you say is a rough distribution of function lengths?  What is the
>> range of lengths, what is the average length, what is the median
>> length?  If you can get exact numbers, so much the better, but
>> rough guesses (assuming they are informed guesses) are fine.
> 
> Unix 1980's stuff is fine, but I don't want to rely on cscope, syntax
> highlighting and other IDE stuff if I don't need it.
> 
> You can see code that mostly meets my style definitions at:
> http://kegs.sourceforge.net/kegs.1.16.tar.gz (some was written almost 30
> years ago and doesn't meet the style guidelines and I have not fixed all
> the problems yet, mostly function and global variable naming issues).  All my
> functions look like:
[...]

Side note, Kegs is great!

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

#167720

kegs@provalid.com (Kent Dickey) writes:

> In article <86a673piw4.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> kegs@provalid.com (Kent Dickey) writes:
>>
[...]
>>> I'm trying to put some protective pads on to avoid C's many
>>> pitfalls, and make it easy to browse code, even without complex
>>> tools.  [...]
>>
>> I'm not sure what kinds of tools you count as "complex tools".
>> Do you mean to avoid using any of the standard utilities that
>> were part of Unix 40+ years ago?  To me it seems silly to design
>> rules assuming such a primitive environment (that is, one where
>> the common Unix utilities of circa 1980 were not present).
>>
>> One question for you:  looking over your own code, what would
>> you say is a rough distribution of function lengths?  What is the
>> range of lengths, what is the average length, what is the median
>> length?  If you can get exact numbers, so much the better, but
>> rough guesses (assuming they are informed guesses) are fine.
>
> Unix 1980's stuff is fine, but I don't want to rely on cscope,
> syntax highlighting and other IDE stuff if I don't need it.

Same here.

> You can see code that mostly meets my style definitions at:
> http://kegs.sourceforge.net/kegs.1.16.tar.gz (some was written
> almost 30 years ago and doesn't meet the style guidelines and I
> have not fixed all the problems yet, mostly function and global
> variable naming issues).

Thank you, it's good to have this example.  I should look at it more
closely but perusing it lightly it looks like your layout choices
are close to my own.

> All my functions look like:
>
> return_type
> function_name(arguments here)
> {
> ...
> }

Same here, except I put the open brace immediately after the
close parenthesis of the function line.

> (Primarily to make [[ and ]] work in vi, but it also makes many
> code grep's easier, the definition of serial_init is /^serial_init
> in vi).

Right.  I use emacs but the idea is the same.

> So I can find the number of functions with:
> grep '^}$' *.c | wc
> and the total lines:
> wc *.c
>
> and I get 36747/756 = 48.6 lines per function (counting all
> overhead outside the functions as well).  ts=8.

Some time ago I wrote a short awk script to tabulate function
statistics.  Running that on your .c sources gives an average of
about 39 lines per function (this measure counts only those lines
inside the outer function braces), with about 9.5% blank lines
(again inside function braces).  To give some ranges, individual
files range from about 5% to just over 18% blank lines (there is
one outlier at 3%), and these number match my own rule of thumb
of between 5% and 20% blank lines.  The range of average lines
per function goes from about 15 lines/function to about 66
lines/function, with one outlier of about 86 lines/function.

For contrast, my own code typically falls in the range of 10-15
lines/function average;  anything over 20 (average; individual
functions can be longer) or so indicates a need to look at
refactoring.

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

#167506

On 8/27/22 19:06, 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

I'll begin by saying that I AM NOT AN EXPERT IN C PROGRAMMING, NOR AM I 
PARTICULARLY GOOD AT GIVING ADVICE.  With that out of the way…

If you are contributing to someone else's project, _**always**_ use the 
style of the surrounding code.  This is the polite thing to do, and it 
means your code won't look out of place.  Maybe you could politely 
discuss changing the project's code style, but until and unless that 
change happens, just use what's already being used.

You should write macros in SCREAMING_CASE.  Macros are unsanitary in C, 
so screaming their names helps to indicate that they can seriously mess 
shit up.

Names should be useful.  Don't name something `fkKFHsna`, because other 
people (including your future self!) will have difficulty trying to 
figure out what it means.  On the other hand, naming a `for` loop's 
iterator `i` or using acronyms like `tmp` is probably okay.

Keep consistency with other names—for example, if alternative 
subroutines that take a `va_list` instead of a `...` are prefixed with a 
"v", don't name yours `original_funcname_with_va_list` or something.

Beyond that…eh, i don't fuckin' know.  Most of this is subjective and 
highly context dependent, so there's not really a "perfect" system of 
names, and trying to impose one would be pointless.  I have some 
personal opinions on the whole matter (never use typedefs, be chaotic, 
dollar signs as hierarchy position separators…), but i don't really feel 
like listing all of them out here.
​
-- 
/blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
I think my Usenet provider stores their passwords in plain text.  If i'm 
acting suspiciously, chances are that that backfired on them.

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

#167616

Use Java's kind of "camelCase" !

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

#167632

On 9/11/2022 10:31 AM, Bonita Montero wrote:
> Use Java's kind of "camelCase" !
> 

For C, usually a:

author_namespace_lib_function

setup.

ct_cairo_2dplot_project

ct_fractal_ttr_compute

ct_cairo_2dplot_project would typically work on a ct_cairo_2dplot struct:

struct ct_cairo_2dplot { ... };



ct_cairo_2dplot_project(struct ct_cairo_2dplot const*, ...)

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

#167868

On Sunday, August 28, 2022 at 12:06:12 AM UTC+1, Thiago Adams wrote:
> I am searching for C naming conventions. 
...
> Any link? What are the "classic ones? " 
> I think one sample is "Win32" API

I aim to consistently use the Big_SmallSmaller scheme, which is the opposite
of the Win32 API. The WinAPI really irritates me, I don't what to know all the
Set* functions when I'm trying to deal with, eg, a Cutter system, I want to know
all the Cutter functions. Using Big_SmallSmaller give me, eg:
Cutter_Init
Cutter_Write
Cutter_Read
Cutter_Copy
Cutter_CopyBuffer
etc., and I use Big_smallsmaller for variables, eg:
Cutter_buffer
Cutter_timeout

whereas the WinAPI naming scheme gives me
InitCutter
InitLCD
InitDiskSubsystem
InitKeyboard
InitSomethingElse
InitAnotherSThing
I don't *CARE* what all the Init calls are. Where the hell are the other
Cutter calls?, I have to *GUESS* them.

For reference, Big_SmallSmaller is used by RISC OS.

jgh

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

#167916

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;

Beyond that, go nuts.  As long as your names are meaningful and convey 
usage properly, the form of that name shouldn't matter, although I will 
say Hungarian notation is an abomination and everyone uses it wrong 
anyway.

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

#167917

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

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

#167927

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>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.

I've been part of the Open Group (nee POSIX) technical committee
since the early 1990's, and what you state could not be further
from the truth.

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

#167920

John Bode <jfbode1029@gmail.com> writes:

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

There are way more than that!  For example 'string' (with external
linkage) is reserved and EIEIO is reserved if you include certain
headers.  The C23 draft has a handy list of patterns to avoid.

-- 
Ben.

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

#167921

[Multipart message — attachments visible in raw view] — view raw

On 9/30/22 19:54, Ben Bacarisse wrote:
> John Bode <jfbode1029@gmail.com> writes:
 >
> [snip]
 >
>> 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;
> 
> There are way more than that!  For example 'string' (with external
> linkage) is reserved and EIEIO is reserved if you include certain
> headers.  The C23 draft has a handy list of patterns to avoid.
>

They won't be soon.  Paper n2625 for C23 turned most of them into merely 
_potentially_ reserved identifiers (underscore-preceeded and 
already-in-use-by-the-standard-library identifiers are still fully 
reserved).
​
-- 
/blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
I think my Usenet provider stores their passwords in plain text.  If i'm 
acting suspiciously, chances are that that backfired on them.

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

#167923

On 2022-10-01, Blue-Maned_Hawk <bluemanedhawk@gmail.com> wrote:
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: base64

s/flowed/flawed/

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

#167922

On 2022-09-30, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
>> 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;
>
> There are way more than that!  For example 'string' (with external
> linkage) is reserved and EIEIO is reserved if you include certain
> headers.  The C23 draft has a handy list of patterns to avoid.

The difference between the leading underscores and "str" and "E",
is that the latter are in a future expansion area of a public namespace.
If they were to appear, they would be documented as new identifiers in
the standard, or else a vendor's extension, like GNU "strfry".

Whereas _ and __ identifiers are a churning toilet bowl. Implementors
invent these at the drop of a hat in any situation they need a
hidden name for any reason that must not clash with application code
in any conceivable way.. E.g. in macro hygiene and whatever.

For instance, a vendor is not going to use "string" as the name of a
local variable generated by a macro, for the sake of hygiene; but they
will use __str, __string, __s and whatever not..

The _ and __ namespaces demand respect in a way that E and str
do not.

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web