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

#167383

On Wednesday, August 31, 2022 at 11:57:46 AM UTC-3, Scott Lurndal wrote:
...
> >What happens when strcmp() dereferences pX->name and tries to 
> >compare the string at NULL to the string "a" ?
> The same thing that happens when strcmp dereferences pX->email when 
> pX == NULL.

In this sample:

strcmp(pX->name,"a"); 

We can see pX is a pointer because of "->", but we cannot see 
if name is a pointer or array. This makes a lot of difference
considering that strcmp don't accept null pointers.

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

#167381

On Wednesday, August 31, 2022 at 11:50:41 AM UTC-3, Lew Pitcher wrote:
> On Wed, 31 Aug 2022 15:30:49 +0100, Ben Bacarisse wrote: 
> 
> > Thiago Adams <thiago...@gmail.com> writes: 
> > 
> >> I was considering prefix when I had this problem. 
> >> 
> >> struct X { 
> >> char * name; char email[100]; 
> >> }; 
> >> 
> >> if (strcmp(pX->name, "a") == ) {} 
> >> if (strcmp(pX->email, "a") == ) {} 
> >> 
> >> Both compiles and have the same syntax. Bust just one of then can 
> >> "explode" that is strcmp(pX->name, "a"). 
> > 
> > What do you mean "explode"? (BTW, I'm assuming struct X *pX;)
> I won't see Thiago's reply. 
> 
> Consider 
> struct X liveX = {NULL,"a"}; 
> struct X *pX = &liveX; 
> 
> strcmp(pX->name,"a"); 
> 
> What happens when strcmp() dereferences pX->name and tries to 
> compare the string at NULL to the string "a" ? 
> 

Yes, this is my point.

#include <string.h>

struct X {
  char * name;
  char email[100];
}; 

void F(struct X* p) {
    if (strcmp(p->name, "name") == 0 || 
        strcmp(p->email, "email") == 0)
    {}
}
int main(){
  struct X x = {0};
  F(&x);
}

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

#167389

Thiago Adams <thiago.adams@gmail.com> writes:

> On Wednesday, August 31, 2022 at 11:50:41 AM UTC-3, Lew Pitcher wrote:
>> On Wed, 31 Aug 2022 15:30:49 +0100, Ben Bacarisse wrote: 
>> 
>> > Thiago Adams <thiago...@gmail.com> writes: 
>> > 
>> >> I was considering prefix when I had this problem. 
>> >> 
>> >> struct X { 
>> >> char * name; char email[100]; 
>> >> }; 
>> >> 
>> >> if (strcmp(pX->name, "a") == ) {} 
>> >> if (strcmp(pX->email, "a") == ) {} 
>> >> 
>> >> Both compiles and have the same syntax. Bust just one of then can 
>> >> "explode" that is strcmp(pX->name, "a"). 
>> > 
>> > What do you mean "explode"? (BTW, I'm assuming struct X *pX;)
>> I won't see Thiago's reply. 
>> 
>> Consider 
>> struct X liveX = {NULL,"a"}; 
>> struct X *pX = &liveX; 
>> 
>> strcmp(pX->name,"a"); 
>> 
>> What happens when strcmp() dereferences pX->name and tries to 
>> compare the string at NULL to the string "a" ? 
>> 
>
> Yes, this is my point.
>
> #include <string.h>
>
> struct X {
>   char * name;
>   char email[100];
> }; 
>
> void F(struct X* p) {
>     if (strcmp(p->name, "name") == 0 || 
>         strcmp(p->email, "email") == 0)
>     {}
> }
> int main(){
>   struct X x = {0};
>   F(&x);
> }

OK.  Not an easy guess for me because email can also "explode" if it's
not null terminated (technically even when compared to "a").  The
initial value of both members determines what operations are valid on
them.

-- 
Ben.

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

#167387

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Wed, 31 Aug 2022 15:30:49 +0100, Ben Bacarisse wrote:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> 
>>> I was considering prefix when I had this problem.
>>>
>>> struct X {
>>>  char * name; char email[100];
>>> };
>>>
>>> if (strcmp(pX->name, "a") == ) {}
>>> if (strcmp(pX->email, "a") == ) {}
>>>
>>> Both compiles and have the same syntax. Bust just one of then can
>>> "explode" that is strcmp(pX->name, "a").
>> 
>> What do you mean "explode"?  (BTW, I'm assuming struct X *pX;)
>
> I won't see Thiago's reply.
>
> Consider
>   struct X liveX = {NULL,"a"};
>   struct X *pX = &liveX;
>
>   strcmp(pX->name,"a");
>
> What happens when strcmp() dereferences pX->name and tries to
> compare the string at NULL to the string "a" ?

Is this what TA meant?  Does he want the naming convention to somew how
prevent this?  Thanks for suggesting a meaning, but I am left with more
questions...

-- 
Ben.

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

#167391

On Wed, 31 Aug 2022 17:50:53 +0100, Ben Bacarisse wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> 
>> On Wed, 31 Aug 2022 15:30:49 +0100, Ben Bacarisse wrote:
>>
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> 
>>>> I was considering prefix when I had this problem.
>>>>
>>>> struct X {
>>>>  char * name; char email[100];
>>>> };
>>>>
>>>> if (strcmp(pX->name, "a") == ) {}
>>>> if (strcmp(pX->email, "a") == ) {}
>>>>
>>>> Both compiles and have the same syntax. Bust just one of then can
>>>> "explode" that is strcmp(pX->name, "a").
>>> 
>>> What do you mean "explode"?  (BTW, I'm assuming struct X *pX;)
>>
>> I won't see Thiago's reply.
>>
>> Consider
>>   struct X liveX = {NULL,"a"};
>>   struct X *pX = &liveX;
>>
>>   strcmp(pX->name,"a");
>>
>> What happens when strcmp() dereferences pX->name and tries to compare
>> the string at NULL to the string "a" ?
> 
> Is this what TA meant?  Does he want the naming convention to somew how
> prevent this?  Thanks for suggesting a meaning, but I am left with more
> questions...

I get the impression that TA is looking for someone to codify
"Systems Hungarian" notation[1] or something similar as either a C
language standard or a "shop" requirement for C programming.

In that case, the example would change to something like:
  struct X {
    char * pszName; char rgchszEmail[100];
  };

  struct X structX = {NULL,"a"};
  struct X *pX = &structX;

  strcmp(pX->pszName,"a");
  strcmp(pX->rgchszEmail,"a");

(Forgive me if I've mangled some of these identifiers. I abhor
Hungarian notation, and do not practice it myself.)

[1] https://en.wikipedia.org/wiki/Hungarian_notation#Systems_Hungarian_vs._Apps_Hungarian

-- 
Lew Pitcher
"In Skills, We Trust"

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

#167392

On Wednesday, August 31, 2022 at 2:14:45 PM UTC-3, Lew Pitcher wrote:
> On Wed, 31 Aug 2022 17:50:53 +0100, Ben Bacarisse wrote: 
> 
> > Lew Pitcher <lew.p...@digitalfreehold.ca> writes: 
> > 
> >> On Wed, 31 Aug 2022 15:30:49 +0100, Ben Bacarisse wrote: 
> >> 
> >>> Thiago Adams <thiago...@gmail.com> writes: 
> >>> 
> >>>> I was considering prefix when I had this problem. 
> >>>> 
> >>>> struct X { 
> >>>> char * name; char email[100]; 
> >>>> }; 
> >>>> 
> >>>> if (strcmp(pX->name, "a") == ) {} 
> >>>> if (strcmp(pX->email, "a") == ) {} 
> >>>> 
> >>>> Both compiles and have the same syntax. Bust just one of then can 
> >>>> "explode" that is strcmp(pX->name, "a"). 
> >>> 
> >>> What do you mean "explode"? (BTW, I'm assuming struct X *pX;) 
> >> 
> >> I won't see Thiago's reply. 
> >> 
> >> Consider 
> >> struct X liveX = {NULL,"a"}; 
> >> struct X *pX = &liveX; 
> >> 
> >> strcmp(pX->name,"a"); 
> >> 
> >> What happens when strcmp() dereferences pX->name and tries to compare 
> >> the string at NULL to the string "a" ? 
> > 
> > Is this what TA meant? Does he want the naming convention to somew how 
> > prevent this? Thanks for suggesting a meaning, but I am left with more 
> > questions...
> I get the impression that TA is looking for someone to codify 
> "Systems Hungarian" notation[1] or something similar as either a C 
> language standard or a "shop" requirement for C programming. 

no..just asking if in this situation a naming convention for "pointer"
or "pointer to string" would be a advantage.
I am not using prefixes but after to see this situation in my code 
I have considered to use a prefix.

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

#167493

Thiago Adams:

> I was considering prefix when I had this problem.
>
> struct X {
>  char * name;
>  char email[100];
> };
>
> if (strcmp(pX->name, "a") == ) {}
> if (strcmp(pX->email, "a") == ) {}
>
> Both compiles and have the same syntax. Bust just
> one of then can "explode" that is strcmp(pX->name, "a").

There are other ways to deal with devilish details than
naming:

  1.  make sure that both .name and .email are proper C
      strings, e.g. by way of a single constructor function
      or dedicated `setter' functions,
  2.  implement explosive operations on X as reusable
      functions,
  3.  work with X as with an opaque type,
  4.  roll your own strcmp that handles NULL.
  5.  generally and when appropriate, follow Robert Martin's
      advice to avoid "primitive obsession".

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#167494

On 31/08/2022 12:37, Thiago Adams wrote:
> On Tuesday, August 30, 2022 at 7:38:29 PM UTC-3, Anton Shepelev wrote:
>> Thiago Adams:
>>> I am searching for C naming conventions. For instance,
>>> how to name structs, function, global variables...
>> I like the minimalist beauty of lowercase indentifers with
>> understores, with constants and macros in uppercase. If
>> need be, I will prefix globals with g_ and function-types
>> with f_. PascalCase is somehow counter-C, and combining it
>> with Under_Scores looks ugly. In C#, I sometimes use
>> BQ_AddToEnd(), but my prefix is stritly a short acronym
>> denoting a sub-module (Binary Queue) withing a module
>> (static class). But then, PascalCase is native to C#.
>>
>>> Any link?
>>
>> The one know one else will give you:
>>
>> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Underscores Discussion
>>
>> It disagrees with my approach, but is worth reading at least
>> for the fun of it.
>>> What are the "classic ones?"
>> The one minimalist one, see K&R.
>>> I think one sample is "Win32" API
>> I hate it for absudly long funtion names and for Hungarian
>> notaiton.
>>
> I was considering prefix when I had this problem.
> 
> struct X {
>   char * name;
>   char email[100];
> };
> 
> if (strcmp(pX->name, "a") == ) {}
> if (strcmp(pX->email, "a") == ) {}
> 
> Both compiles and have the same syntax. Bust just
> one of then can "explode" that is strcmp(pX->name, "a").

Both can 'explode', for example when .email is not properly initialised 
and can be full of non-zero-terminated garbage.

If you mean that, even if an instance of struct X is zeroed, then .email 
is in a safe state but .name can be NULL, then I don't know how naming 
will help much.

I usually assume such strings can be NULL anyway, as can .email be if at 
some point you decide to change how it's implemented, but you don't 
really want to go about changing all the names.

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

#167505

On Monday, September 5, 2022 at 5:44:55 PM UTC-3, Bart wrote:
> On 31/08/2022 12:37, Thiago Adams wrote: 
> > On Tuesday, August 30, 2022 at 7:38:29 PM UTC-3, Anton Shepelev wrote: 
> >> Thiago Adams: 
> >>> I am searching for C naming conventions. For instance, 
> >>> how to name structs, function, global variables... 
> >> I like the minimalist beauty of lowercase indentifers with 
> >> understores, with constants and macros in uppercase. If 
> >> need be, I will prefix globals with g_ and function-types 
> >> with f_. PascalCase is somehow counter-C, and combining it 
> >> with Under_Scores looks ugly. In C#, I sometimes use 
> >> BQ_AddToEnd(), but my prefix is stritly a short acronym 
> >> denoting a sub-module (Binary Queue) withing a module 
> >> (static class). But then, PascalCase is native to C#. 
> >> 
> >>> Any link? 
> >> 
> >> The one know one else will give you: 
> >> 
> >> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Underscores Discussion 
> >> 
> >> It disagrees with my approach, but is worth reading at least 
> >> for the fun of it. 
> >>> What are the "classic ones?" 
> >> The one minimalist one, see K&R. 
> >>> I think one sample is "Win32" API 
> >> I hate it for absudly long funtion names and for Hungarian 
> >> notaiton. 
> >> 
> > I was considering prefix when I had this problem. 
> > 
> > struct X { 
> > char * name; 
> > char email[100]; 
> > }; 
> > 
> > if (strcmp(pX->name, "a") == ) {} 
> > if (strcmp(pX->email, "a") == ) {} 
> > 
> > Both compiles and have the same syntax. Bust just 
> > one of then can "explode" that is strcmp(pX->name, "a").
> Both can 'explode', for example when .email is not properly initialised 
> and can be full of non-zero-terminated garbage. 
> 
> If you mean that, even if an instance of struct X is zeroed, then .email 
> is in a safe state but .name can be NULL, then I don't know how naming 
> will help much. 

I am considering a valid estate that is  - empty string. 
But empty string have different representation, unless we allocate "\0"
for the pointer version.
So basically is not about invalid/wrong states..is about valid states
having different semantics that can be dangerous.

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

#167611

On Wednesday, August 31, 2022 at 8:37:32 AM UTC-3, Thiago Adams wrote:
[...]
> I was considering prefix when I had this problem. 
> 
> struct X { 
> char * name; 
> char email[100]; 
> }; 
> 
> if (strcmp(pX->name, "a") == ) {} 
> if (strcmp(pX->email, "a") == ) {} 
> 
> Both compiles and have the same syntax. Bust just 
> one of then can "explode" that is strcmp(pX->name, "a").


I was removing the prefix 'p' for pointers in my code, especially for structs
because generally they are used with "->" so it is clear that is a pointer.
Then I found

struct macro* macro = calloc(1, sizeof * macro);

Here the prefix "p" for "macro" can be useful because "->" is
not present. The result is completely different.

For this particular case we can do
struct macro* macro = calloc(1, sizeof (struct macro));

Another item I found difficult is the prefix "b" for bool.
When "is" or "has" can be used it is easy.

bool is_enabled;
bool has_something;

the problem is when it is like a verb.

void F(struct Something * s, bool bAddHeader){}
void F(struct Something * s, bool bEnableCheck){}

What names do you use in this case? (for those don't use prefix b)
Just enable_check and add_header ? 

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

#167617

Thiago Adams <thiago.adams@gmail.com> writes:

> On Wednesday, August 31, 2022 at 8:37:32 AM UTC-3, Thiago Adams wrote:
> [...]
>> I was considering prefix when I had this problem. 
>> 
>> struct X { 
>> char * name; 
>> char email[100]; 
>> }; 
>> 
>> if (strcmp(pX->name, "a") == ) {} 
>> if (strcmp(pX->email, "a") == ) {} 
>> 
>> Both compiles and have the same syntax. Bust just 
>> one of then can "explode" that is strcmp(pX->name, "a").
>
>
> I was removing the prefix 'p' for pointers in my code, especially for structs
> because generally they are used with "->" so it is clear that is a pointer.
> Then I found
>
> struct macro* macro = calloc(1, sizeof * macro);
>
> Here the prefix "p" for "macro" can be useful because "->" is
> not present. The result is completely different.

I don't understand the last sentence, but I also don't understand why
you think it's not clear that macro is a pointer from that line.

My own opinion is that the distinction between an object and a pointer
to an object is so important it /should/ be part of the name.  I don't
like unreadable prefixes, but I often write things line macro_ptr.

I also prefer to reflect the syntax (and meaning) in the layout so I'd
tick the * to the name.  I /try/ not to react when I see int* p, but
it's a hard internal struggle.  I would never want to write it, any more
than I would want to write a+2 * b instead of a + 2*b.

> For this particular case we can do
> struct macro* macro = calloc(1, sizeof (struct macro));

How does that make any difference?  I'm obviously missing something here.

> Another item I found difficult is the prefix "b" for bool.
> When "is" or "has" can be used it is easy.
>
> bool is_enabled;
> bool has_something;
>
> the problem is when it is like a verb.
>
> void F(struct Something * s, bool bAddHeader){}
> void F(struct Something * s, bool bEnableCheck){}

As far as possible, I try to avoid this sort of thing ("pass data to
functions, not control") but when cornered, I'd just use the verb as you
suggest here:

> What names do you use in this case? (for those don't use prefix b)
> Just enable_check and add_header?

What else could a Boolean verb mean other than to do the thing or not do
it?  The trouble is, though, that in languages without named arguments
in function calls, the meaning of argument (rather than the parameter)
is lost to the reader:

  F(struct_ptr, true);
  F(struct_ptr, size < max_size);

-- 
Ben.

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

#167620

On Sunday, September 11, 2022 at 4:33:32 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > On Wednesday, August 31, 2022 at 8:37:32 AM UTC-3, Thiago Adams wrote: 
> > [...] 
> >> I was considering prefix when I had this problem. 
> >> 
> >> struct X { 
> >> char * name; 
> >> char email[100]; 
> >> }; 
> >> 
> >> if (strcmp(pX->name, "a") == ) {} 
> >> if (strcmp(pX->email, "a") == ) {} 
> >> 
> >> Both compiles and have the same syntax. Bust just 
> >> one of then can "explode" that is strcmp(pX->name, "a"). 
> > 
> > 
> > I was removing the prefix 'p' for pointers in my code, especially for structs 
> > because generally they are used with "->" so it is clear that is a pointer. 
> > Then I found 
> > 
> > struct macro* macro = calloc(1, sizeof * macro); 
> > 
> > Here the prefix "p" for "macro" can be useful because "->" is 
> > not present. The result is completely different.
> I don't understand the last sentence, but I also don't understand why 
> you think it's not clear that macro is a pointer from that line. 

I was worried about a mistake like

macro = calloc(1, sizeof  macro); 

when trying to write
macro = calloc(1, sizeof  * macro); 

The prefix "p" would have the advantage of making it
a little more explicit.

macro = calloc(1, sizeof  pmacro);  //Visually.. What? sizeof of pointer ?

(But I am still removing prefix from my code and I want do see 
what happens)

The correct code has the "* " in front of the macro, so the correct
code has the information we want the size of the object not the pointer.

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

#167627

On Sunday, September 11, 2022 at 2:33:32 PM UTC-5, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > On Wednesday, August 31, 2022 at 8:37:32 AM UTC-3, Thiago Adams wrote: 
> > [...] 
> >> I was considering prefix when I had this problem. 
> >> 
[snip]
> > Another item I found difficult is the prefix "b" for bool. 
> > When "is" or "has" can be used it is easy. 
> > 
> > bool is_enabled; 
> > bool has_something; 
> > 
> > the problem is when it is like a verb. 
> > 
> > void F(struct Something * s, bool bAddHeader){} 
> > void F(struct Something * s, bool bEnableCheck){}
> As far as possible, I try to avoid this sort of thing ("pass data to 
> functions, not control") but when cornered, I'd just use the verb as you 
> suggest here:
> > What names do you use in this case? (for those don't use prefix b) 
> > Just enable_check and add_header?
> What else could a Boolean verb mean other than to do the thing or not do 
> it? The trouble is, though, that in languages without named arguments 
> in function calls, the meaning of argument (rather than the parameter) 
> is lost to the reader: 
> 
> F(struct_ptr, true); 
> F(struct_ptr, size < max_size); 
> 

For this problem, it can be nice to use a custom enum even though it's 
logically a boolean in disguise.

  enum { DO_NOT_ADD_HEADER, ADD_HEADER };
  enum { NO_ENABLE_CHECK, ENABLE_CHECK };

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

#167633

luser droog <luser.droog@gmail.com> writes:

> On Sunday, September 11, 2022 at 2:33:32 PM UTC-5, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes: 
>> 
>> > On Wednesday, August 31, 2022 at 8:37:32 AM UTC-3, Thiago Adams wrote: 
>> > [...] 
>> >> I was considering prefix when I had this problem. 
>> >> 
> [snip]
>> > Another item I found difficult is the prefix "b" for bool. 
>> > When "is" or "has" can be used it is easy. 
>> > 
>> > bool is_enabled; 
>> > bool has_something; 
>> > 
>> > the problem is when it is like a verb. 
>> > 
>> > void F(struct Something * s, bool bAddHeader){} 
>> > void F(struct Something * s, bool bEnableCheck){}
>> As far as possible, I try to avoid this sort of thing ("pass data to 
>> functions, not control") but when cornered, I'd just use the verb as you 
>> suggest here:
>> > What names do you use in this case? (for those don't use prefix b) 
>> > Just enable_check and add_header?
>> What else could a Boolean verb mean other than to do the thing or not do 
>> it? The trouble is, though, that in languages without named arguments 
>> in function calls, the meaning of argument (rather than the parameter) 
>> is lost to the reader: 
>> 
>> F(struct_ptr, true); 
>> F(struct_ptr, size < max_size); 
>
> For this problem, it can be nice to use a custom enum even though it's 
> logically a boolean in disguise.
>
>   enum { DO_NOT_ADD_HEADER, ADD_HEADER };
>   enum { NO_ENABLE_CHECK, ENABLE_CHECK };

My preference is to have only enum { ENABLE_CHECK = true }; (or = 1) and
use !ENABLE_CHECK.  The ! gets a bit hidden but it can help to make
clear that this is Boolean in disguise.

But using an enum gets ugly and long-winded in the second example,
unless you are prepared to write

  F(struct_ptr, ENABLE_CHECK * (size < max_size));

which would give most people here the heebee-jeebies.

-- 
Ben.

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

#167354

On Saturday, August 27, 2022 at 6:06:12 PM UTC-5, 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 dug into this area 10 years or so, even reading the paper by Simonyi, but
IMO the best result here is "Apps Hungarian" where you pretty much don't
do it at all like everybody else has continued to do it. The Win32 is an 
appropriately horrible example that illustrates why "Systems Hungarian"
is just awful. 

I'll describe the conventions I've applied in my parser combinators which
I'm reasonably happy with. Other may disagree. And this may or may not
fit any rigorous definition for Apps Hungarian that may have arisen in the 
interim from the time I actually looked at this.

I use plain old lowercase words for type names, and the Capitalized
version of the same word for the associated constructor for that type.
The all-caps version of the same word is used in the tag field for the
structs for dynamic type dispatching.

Function names (in this "functional style" code body) ought to reflect 
what the result value is, and so tend to be more adjectives and past tense
verbs.

A function that "does something" rather than produce something should 
be a verb in the imperative mood. A function producing a function object
that "does something" should be the same verb but in the present tense
indicative mood.

Eg. 

  static object
  fail( object errormsg, list input );

is a parsing function which always fails when called.

  parser  fails( list errormsg );

is a constructor which produces the function object which couples
the `fail` parsing function and it's saved argument.

An example function names that describe the result rather that what
it's doing:

  list    ucs4_from_utf8( list o );
  list    utf8_from_ucs4( list o );

They're both doing stream conversion, but the function name would
just be cluttered if those words (or worse, abbreviations) crept in there.

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

#167492

In article <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com>,
Thiago Adams  <thiago.adams@gmail.com> 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

Most people know they need some convention.  Most people hate any particular
convention.  Pick a convention for a project, stick to it, change conventions
for a new project.  Go ahead and let sub-projects (or libraries to the
project) try new conventions, as long as they are roughly compatible, or are
so different as to be obvious.  Don't mix conventions within a file ever.

I'll summarize my rules:
All structs must be typedef'ed and the typedef name is an initial capital.
All structs are created by STRUCT(Sample_structure) where STRUCT is:
	#define STRUCT(a) typedef struct a ## _st a; struct a ## _st
The word "struct" and "typedef" should never appear in any code, other than
	the STRUCT #define.
	This means there is no typedef char **Ptr_str; nonsense to decode.
	If you see "struct", it means this is for a library/OS call.
Global variables start with an initial cap (like typedef names), or g_.
	Make a distinction between them only if needed--I have some global
	variables which are special, so they get the initial capital, all the
	rest are g_.
Structure fields follow the local variable rules.
Local variable and function names are all lower case.
All names use _ and not CamelCase.  I think this works best when you use
	libs which are CamelCase, since it's easy to tell when you are calling
	outside your code.  If this hurts your eyes, then get new glasses.
All #defines are all-caps.  No other identifier can be all-cap.
	"#define NUM_THINGS 5" is fine.  #define FUNC_THIS(a) must have 
	"(a)" on the right hand side in all instances.  Anything more complex
	than a single number or variable must wrap the definition with ().
Enums are like structures and are Initial_capital for the type.  It's
	easy to tell these apart from structs.
	I'm ambivalent on enums vs #defines, but enums of arbitrary things
	should start at 1 so that 0 is always an error value.
Function names include the file name (or a short form of it) as a prefix.
	So serial.c would have serial_init(), serial_out_char(), etc.
	But windows_serial.c could be wser_init(), etc, just to shorten things.
	All functions in one file must use the same prefix.
I have a simple hungarian notation: 64-bit variables have a 'd' in the name
	that is meaningful: "dval", "init_dtmp".  "do_this" is not 64-bit.
	Pointers have "ptr" in the name somewhere, often at the end (but
	"userptr2" is fine), except char * pointers should use "str" in the
	name somewhere.  Non pointers variables never have str or ptr
	in the name.  For your app, try to use consistent names:  Don't let
	"val" be unsigned sometimes and signed other times.  Pick a convention
	and stick with it.  I like val to be unsigned, and tmp to be signed.
	So last_val is unsigned, and prev_tmp is an int.
	Loop counters can be i,j,k, but all other variables should briefly
	describe what it is.  "tmp" or "val" are only ok for brief usage.
Declaring variables never initializes them, except for global variables.
	Use -Wall -Werror to ensure everything is initialized.  This is so
	the declarations can be ignored when reading code since they
	provide no new information.
When passing around an array, always use &array[0] notation to indicate
	"array" is an array and not a pointer.

The advantage of this is you can begin reading any file and have an idea
what functions it's calling and even what work it's doing, without
having to constantly look at header files or variable declarations.  And
the light Hungarian notation means you don't have to read declarations,
so I pack them tightly with many variables per line just to be done with
them.  Variables are declared in order by type: arrays, then pointers,
then ints, and by size within each type.  It's not legal to mix pointers
and ints in declarations, so you cannot do: "int a, *ptr1, b, c[100];"

I use special typedefs for unsigned types: byte, word16, word32, and dword64
of the obvious sizes.  These are the only typedefs that are not structures
and are not capitalized.  I'm less likely to mix them up since byte,
word32, and dword64 are all different lengths and multiple keystrokes
apart: word64 and dword32 are not valid.  It's hard to tell uint32_t
from uint64_t, they tend to blend together to my eyes in large
structures, and getting them mixed up is a very annoying bug.

Kent

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

#167640

kegs@provalid.com (Kent Dickey) writes:

> In article <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com>,
> Thiago Adams  <thiago.adams@gmail.com> 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
>
> Most people know they need some convention.  Most people hate any particular
> convention.  Pick a convention for a project, stick to it, change conventions
> for a new project.  Go ahead and let sub-projects (or libraries to the
> project) try new conventions, as long as they are roughly compatible, or are
> so different as to be obvious.  Don't mix conventions within a file ever.
>
> I'll summarize my rules:

An interesting set of ideas.  Comments are offered in some select
cases.


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


> The word "struct" and "typedef" should never appear in any code, other than
>     the STRUCT #define.
>     This means there is no typedef char **Ptr_str; nonsense to decode.
>     If you see "struct", it means this is for a library/OS call.

I have a different view regarding other typedefs.  However I
think I understand your motivations, and won't argue the point.


> Structure fields follow the local variable rules.

My instinctive reaction is that the rules for struct members
should be more stringent than the rules for local variables.
That said, this rule is a good baseline.


> Local variable and function names are all lower case.

Of course (with some allowances for acronyms, which might appear
as all-capitals "words" within a larger all lower case context).


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


> All #defines are all-caps.  No other identifier can be all-cap.
>     "#define NUM_THINGS 5" is fine.  #define FUNC_THIS(a) must have
>     "(a)" on the right hand side in all instances.  Anything more complex
>     than a single number or variable must wrap the definition with ().

Generally yes;  there may be exceptions in some special cases.


> Function names include the file name (or a short form of it) as a prefix.
>     So serial.c would have serial_init(), serial_out_char(), etc.
>     But windows_serial.c could be wser_init(), etc, just to shorten things.
>     All functions in one file must use the same prefix.

Having a prefix seems reasonable.  Insisting that the prefix be
tied to the file name seems excessive.


> I have a simple hungarian notation: 64-bit variables have a 'd' in the name
>     that is meaningful:  "dval", "init_dtmp".  "do_this" is not 64-bit.
>     Pointers have "ptr" in the name somewhere, often at the end (but
>     "userptr2" is fine), except char * pointers should use "str" in the
>     name somewhere.  Non pointers variables never have str or ptr
>     in the name.  For your app, try to use consistent names:  Don't let
>     "val" be unsigned sometimes and signed other times.  Pick a convention
>     and stick with it.  I like val to be unsigned, and tmp to be signed.
>     So last_val is unsigned, and prev_tmp is an int.
>     Loop counters can be i,j,k, but all other variables should briefly
>     describe what it is.  "tmp" or "val" are only ok for brief usage.

IMO encoding the type of a variable in its name is just wrong.
If a function has so many names that it's difficult to remember
what types go with which names then the function is too big.  For
global names or struct members, if knowing the types is any
significant burden then any uses of those names should be
encapsulated, reducing their surface area.


> Declaring variables never initializes them, except for global variables.
>     Use -Wall -Werror to ensure everything is initialized.  This is so
>     the declarations can be ignored when reading code since they
>     provide no new information.

Interesting argument.  I may try adopting this rule for a while.


> When passing around an array, always use &array[0] notation to indicate
>     "array" is an array and not a pointer.

I follow a different rule:  'array' by itself means the whole
array, '&array[0]' means just the one element is referenced.


> The advantage of this is you can begin reading any file and have an idea
> what functions it's calling and even what work it's doing, without
> having to constantly look at header files or variable declarations.  And
> the light Hungarian notation means you don't have to read declarations,
> so I pack them tightly with many variables per line just to be done with
> them.  Variables are declared in order by type:  arrays, then pointers,
> then ints, and by size within each type.  It's not legal to mix pointers
> and ints in declarations, so you cannot do:  "int a, *ptr1, b, c[100];"

My sense is that these motivations assume a style of coding that
is different from my usual style(s).  And hence, consequently,
work better in some coding/development styles than others.  It
would be interesting to explore that question further at some
point.


> I use special typedefs for unsigned types:  byte, word16, word32, and dword64
> of the obvious sizes.  These are the only typedefs that are not structures
> and are not capitalized.  I'm less likely to mix them up since byte,
> word32, and dword64 are all different lengths and multiple keystrokes
> apart:  word64 and dword32 are not valid.  It's hard to tell uint32_t
> from uint64_t, they tend to blend together to my eyes in large
> structures, and getting them mixed up is a very annoying bug.

IMO using type names like word32 or dword64 (or uint32_t or
uint64_t) in open code is generally a bad idea.  So here again I
expect that the efficacy of these particular rules depends on
program style on a larger scale.

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

#167659

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.

>
>> All #defines are all-caps.  No other identifier can be all-cap.
>>     "#define NUM_THINGS 5" is fine.  #define FUNC_THIS(a) must have
>>     "(a)" on the right hand side in all instances.  Anything more complex
>>     than a single number or variable must wrap the definition with ().
>
>Generally yes;  there may be exceptions in some special cases.
>
>
>> Function names include the file name (or a short form of it) as a prefix.
>>     So serial.c would have serial_init(), serial_out_char(), etc.
>>     But windows_serial.c could be wser_init(), etc, just to shorten things.
>>     All functions in one file must use the same prefix.
>
>Having a prefix seems reasonable.  Insisting that the prefix be
>tied to the file name seems excessive.

I can return to code I wrote 20 years ago and navigate it manually without
grep.  I use abbreviations, so customer_input.c would name the functions
ci_().

>> I have a simple hungarian notation: 64-bit variables have a 'd' in the name
>>     that is meaningful:  "dval", "init_dtmp".  "do_this" is not 64-bit.
>>     Pointers have "ptr" in the name somewhere, often at the end (but
>>     "userptr2" is fine), except char * pointers should use "str" in the
>>     name somewhere.  Non pointers variables never have str or ptr
>>     in the name.  For your app, try to use consistent names:  Don't let
>>     "val" be unsigned sometimes and signed other times.  Pick a convention
>>     and stick with it.  I like val to be unsigned, and tmp to be signed.
>>     So last_val is unsigned, and prev_tmp is an int.
>>     Loop counters can be i,j,k, but all other variables should briefly
>>     describe what it is.  "tmp" or "val" are only ok for brief usage.
>
>IMO encoding the type of a variable in its name is just wrong.
>If a function has so many names that it's difficult to remember
>what types go with which names then the function is too big.  For
>global names or struct members, if knowing the types is any
>significant burden then any uses of those names should be
>encapsulated, reducing their surface area.

My rules are a pushback against needless abstraction.  The idea is I can
read a line of code, and have a very good idea of what it's doing without
having to chase down the declarations of the function definition.  For
example:

	foo(a, b, c, d);

could be passing 4 integers.  It could be passing 4 arrays.  It could be
passing two function pointers, and integer, and a struct.

With my style, it has to be passing 4 integers (of some size).  This is
why passing an array has to do &a[0], since 'a' could mean anything.  It
also makes it clear that the array needs some sort of size to be passed
as well.  Passing a structure is always:

	Thing my_thing;

	...
	foo(&my_thing);

where & and a variable is almost always a struct, can be an integer rarely.

>> Declaring variables never initializes them, except for global variables.
>>     Use -Wall -Werror to ensure everything is initialized.  This is so
>>     the declarations can be ignored when reading code since they
>>     provide no new information.
>
>Interesting argument.  I may try adopting this rule for a while.
>
>
>> When passing around an array, always use &array[0] notation to indicate
>>     "array" is an array and not a pointer.
>
>I follow a different rule:  'array' by itself means the whole
>array, '&array[0]' means just the one element is referenced.

I get that, but I want to never be confused about passing around
an array vs. an integer.  A lot of my rules are in reaction to reading large
programs, like Linux, where you have to have lots of windows open looking
at headers to even get a vague idea what's going on in one function.

>> The advantage of this is you can begin reading any file and have an idea
>> what functions it's calling and even what work it's doing, without
>> having to constantly look at header files or variable declarations.  And
>> the light Hungarian notation means you don't have to read declarations,
>> so I pack them tightly with many variables per line just to be done with
>> them.  Variables are declared in order by type:  arrays, then pointers,
>> then ints, and by size within each type.  It's not legal to mix pointers
>> and ints in declarations, so you cannot do:  "int a, *ptr1, b, c[100];"
>
>My sense is that these motivations assume a style of coding that
>is different from my usual style(s).  And hence, consequently,
>work better in some coding/development styles than others.  It
>would be interesting to explore that question further at some
>point.
>
>
>> I use special typedefs for unsigned types:  byte, word16, word32, and dword64
>> of the obvious sizes.  These are the only typedefs that are not structures
>> and are not capitalized.  I'm less likely to mix them up since byte,
>> word32, and dword64 are all different lengths and multiple keystrokes
>> apart:  word64 and dword32 are not valid.  It's hard to tell uint32_t
>> from uint64_t, they tend to blend together to my eyes in large
>> structures, and getting them mixed up is a very annoying bug.
>
>IMO using type names like word32 or dword64 (or uint32_t or
>uint64_t) in open code is generally a bad idea.  So here again I
>expect that the efficacy of these particular rules depends on
>program style on a larger scale.

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 interested
in learning other strategies, but I find most coding guidelines try to
do some useful things, but then don't really achieve it due to pushback,
so you have the worst of all worlds: constraints that annoy everyone without
much benefit.

Perl had the motto "There's more than one way to do it", and my reaction
is that's a bad thing.  It's just too hard to deal with a code base
using so many language features that no one really understands.  And
"don't do this" lists end up reinforcing bad ways, since you're
basically saying "Don't think about flowers", and then everyone
thinks about flowers.  If you say "don't use goto", everyone starts
thinking of ways to use goto.  But if you say, "handle errors by
returning negative numbers, and never return negative numbers
otherwise", you don't reinforce all the other ways to do it.

Kent

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

#167660

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

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

#167669

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>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, ...

At the time when the Posix 1003.4 working group was standardizing
a threading interface, there were already several competing
unix-based threading implementations existing.   None of which
had the same API or API semantics (e.g. DIGITAL threads or
System V 4.2 M-N threads, or SunOs threads).   Therefore, using 'mutex_',
'thread_' prefixes would have conflicted with existing proprietary
implementations.   Thus, the nomenclature you're complaining
about was developed to avoid conflicts with existing code.

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

Stupid is a pretty strong word for someone who wasn't there at
the time.

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

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

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

csiph-web