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

Groups > comp.lang.c > #167633

Re: C naming conventions

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: C naming conventions
Date 2022-09-12 11:51 +0100
Organization A noiseless patient Spider
Message-ID <87a674yifw.fsf@bsb.me.uk> (permalink)
References (1 earlier) <20220831013815.a0e201e18452d8a859800db9@gmail.com> <98bb37c0-c9cb-47b5-a7d2-a3423b7dfab1n@googlegroups.com> <4c744fba-b0b1-4e14-a800-e965f09572c0n@googlegroups.com> <87wna9zoxt.fsf@bsb.me.uk> <b67efa49-81a6-4cba-a785-59431d06b176n@googlegroups.com>

Show all headers | View raw

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.

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