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

Groups > comp.lang.c > #167617

Re: C naming conventions

Show all headers | View raw

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.

Back to comp.lang.c | Previous | Next — Previous 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