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

#167247 — C naming conventions

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

[toc] | [next] | [standalone]

#167248

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

Conventions changed with tools.  Early ones has to cope
with case insentitive linkers which allowed only 6
significant characters in name.  So you got elaborate
schemes to put some info into name, but for bigger
systems after some evolution people ended with
complete nonsense.  Of course, people familiar
with system memorised frequently used names,
but it was hard for newcomers.

I normaly use rather long names with parts separated
by underscores.  I am trying to use sensible names
without makeing them too long.  For example, in
small program I have:

#define MAX_NAME_LENGTH 30
#define MAX_NAMES 500
typedef struct {char name[MAX_NAME_LENGTH]; void * val;} symtab_pos;

As you can see for macro constants I prefer uppercase, normal
names almost exclusively lowercase.  In bigger program anything
global would get prefix corresonding to module/sybsustem.
For local variables I use i, j, x and similar.

There is CamelCase camp.  Concering Win32 API they have part
under influence of hungarian notation, which basically tries
to put type information in few characters and use them as
part of name.  This makes some sense for baroque interfaces
like Win API, but I would avoid this for my code.

-- 
                              Waldek Hebisch

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

#167278

On Saturday, August 27, 2022 at 8:43:04 PM UTC-3, anti...@math.uni.wroc.pl wrote:
> Thiago Adams <thiago...@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
> Conventions changed with tools. Early ones has to cope 
> with case insentitive linkers which allowed only 6 
> significant characters in name. So you got elaborate 
> schemes to put some info into name, but for bigger 
> systems after some evolution people ended with 
> complete nonsense. Of course, people familiar 
> with system memorised frequently used names, 
> but it was hard for newcomers. 
>
Interesting.

> I normaly use rather long names with parts separated 
> by underscores. 

One advantage I see in camelCase or pascal Case is that using underscore
can separate two blocks one being the "subject "

Window_SetText()
Window_SetPos()

compare with
window_set_pos()

>I am trying to use sensible names 
> without makeing them too long. For example, in 
> small program I have: 
> 
> #define MAX_NAME_LENGTH 30 
> #define MAX_NAMES 500 
> typedef struct {char name[MAX_NAME_LENGTH]; void * val;} symtab_pos; 
> 
> As you can see for macro constants I prefer uppercase, normal 

Upper case for macros are good to put then in a separate  "namespace".
and the bigger names are useful anyway because they are global

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

#167316

On Sunday, August 28, 2022 at 10:42:40 PM UTC-5, Thiago Adams wrote:
> On Saturday, August 27, 2022 at 8:43:04 PM UTC-3, anti...@math.uni.wroc.pl wrote: 
> > I normaly use rather long names with parts separated 
> > by underscores.
> One advantage I see in camelCase or pascal Case is that using underscore 
> can separate two blocks one being the "subject " 
> 
> Window_SetText() 
> Window_SetPos() 
> 
> compare with 
> window_set_pos()

Upon first reading this, I thought "ooh, that's neat." Then searching my memory for
where such a thing might be needed I remembered that I've already done this before.

In my PostScript interpreter, there's a struct Xpost_Memory_File which describes
the whole memory space in which the language objects live. But there's also a
struct Xpost_MemoryFile which is a subclass of struct Xpost_File presenting
a FILE interface to a block of memory.

And reflecting upon that, it may indeed be "neat" but it's also goddoffal. I wish I had
come up with a better way to distinguish these very different things than the
presence or absence of a single underscore. It's still the same words. When I 
verbalize the code it in my head while reading it, the underscores disappear.
You can kinda sound the words closer to together to reflect the difference, but ...
there's got to be a better way. There just has to. In my opinion. FWIW.

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

#167345

On Monday, August 29, 2022 at 11:13:04 PM UTC-3, luser droog wrote:
> On Sunday, August 28, 2022 at 10:42:40 PM UTC-5, Thiago Adams wrote: 
> > On Saturday, August 27, 2022 at 8:43:04 PM UTC-3, anti...@math.uni.wroc.pl wrote: 
> > > I normaly use rather long names with parts separated 
> > > by underscores. 
> > One advantage I see in camelCase or pascal Case is that using underscore 
> > can separate two blocks one being the "subject " 
> > 
> > Window_SetText() 
> > Window_SetPos() 
> > 
> > compare with 
> > window_set_pos()
> Upon first reading this, I thought "ooh, that's neat." Then searching my memory for 
> where such a thing might be needed I remembered that I've already done this before. 
> 

These samples are from Win23 GDI. "Pen" is a object it has a handle.

CreatePen 	
CreatePenIndirect
ExtCreatePen
SetDCPenColor

The word "Pen" is present in all function but not as prefix like:

Pen_Create
Pen_CreateIndirect
Pen_ExtCreate
Pen_SetDCColor

Does anyone have a preference?
The advange of CreatePen 	 is no need for "_"
and the advantage of Pen_Create is auto complete in modern IDEs.

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

#167347

Le 30/08/2022 à 19:54, Thiago Adams a écrit :
> On Monday, August 29, 2022 at 11:13:04 PM UTC-3, luser droog wrote:
>> On Sunday, August 28, 2022 at 10:42:40 PM UTC-5, Thiago Adams wrote:
>>> On Saturday, August 27, 2022 at 8:43:04 PM UTC-3, anti...@math.uni.wroc.pl wrote:
>>>> I normaly use rather long names with parts separated
>>>> by underscores.
>>> One advantage I see in camelCase or pascal Case is that using underscore
>>> can separate two blocks one being the "subject "
>>>
>>> Window_SetText()
>>> Window_SetPos()
>>>
>>> compare with
>>> window_set_pos()
>> Upon first reading this, I thought "ooh, that's neat." Then searching my memory for
>> where such a thing might be needed I remembered that I've already done this before.
>>
> 
> These samples are from Win23 GDI. "Pen" is a object it has a handle.
> 
> CreatePen 	
> CreatePenIndirect
> ExtCreatePen
> SetDCPenColor
> 
> The word "Pen" is present in all function but not as prefix like:
> 
> Pen_Create
> Pen_CreateIndirect
> Pen_ExtCreate
> Pen_SetDCColor
> 
> Does anyone have a preference?
> The advange of CreatePen 	 is no need for "_"
> and the advantage of Pen_Create is auto complete in modern IDEs.

I personally use underscores and prefixes to indicate "hierarchy". I 
will thus tend to prefer the latter version, although in my code, it 
would probably have additional prefixes if the "Pen" functions are part 
of some "module" or library. So that would more look like (for instance):

GDI_Pen_Create

Yes, that's a lot of underscores. Yes, that's partly because C doesn't 
have modules, classes or even separate namespaces. But I don't mind. 
Auto-complete works in all decent text editors I have used. They don't 
even have to be ultra-modern or trendy.

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

#167299

On Saturday, August 27, 2022 at 8:06:12 PM UTC-3, 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

NASA  C Style
From August 1, 1994 
https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf

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

#167305

Le 29/08/2022 à 18:02, Thiago Adams a écrit :
> On Saturday, August 27, 2022 at 8:06:12 PM UTC-3, 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
> 
> NASA  C Style
>  From August 1, 1994
> https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf

That's interesting. Turns out there's a lot in there that closely 
matches my own style. Except for the naming convention! For which I do 
favor CamelCase for all identifiers, and as the Window_SetText() example 
you gave, I also use underscores to indicate hierarchical structure.

And for types, I suffix them with '_t' as the C standard does.

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

#167312

On Monday, August 29, 2022 at 3:07:10 PM UTC-3, Opus wrote:
> Le 29/08/2022 à 18:02, Thiago Adams a écrit : 
> > On Saturday, August 27, 2022 at 8:06:12 PM UTC-3, 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 
> > 
> > NASA C Style 
> > From August 1, 1994 
> > https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf
> That's interesting. Turns out there's a lot in there that closely 
> matches my own style. Except for the naming convention! For which I do 
> favor CamelCase for all identifiers, and as the Window_SetText() example 
> you gave, I also use underscores to indicate hierarchical structure. 
> 
> And for types, I suffix them with '_t' as the C standard does.

One "problem" with camel case is that c functions like fopen etc..
does not follow the rule resulting in a mixed style.

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

#167314

On Monday, August 29, 2022 at 10:15:45 PM UTC-3, Thiago Adams wrote:
..> One "problem" with camel case is that c functions like fopen etc.. 
> does not follow the rule resulting in a mixed style.

if we try to follow the existing c style..then we have more than one style

error constants

enum {

    thrd_success = /* unspecified */,
    thrd_nomem = /* unspecified */,
    thrd_timedout = /* unspecified */,
    thrd_busy = /* unspecified */,
    thrd_error = /* unspecified */
};

other constants
enum memory_order {

    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
};
macros
#define LC_ALL      /*implementation defined*/		
#define LC_COLLATE  /*implementation defined*/
..

and some posix errors are UPPER

typedef is sometimes upper

typedef /* unspecified */ FILE;
	
or
thrd_t 	implementation-defined complete object type identifying a thread

functions

int thrd_create( thrd_t *thr, thrd_start_t func, void *arg );

or
void atomic_signal_fence( memory_order order );

or
 
strcmp
int isgreater(real-floating x, real-floating y);
int isgreaterequal(real-floating x, real-floating y);

bool ckd_mul(type1 *result, type2 a, type3 b


 macros sometimes are lowecase

stderr, offsetof, errno
int isless(real-floating x, real-floating y);

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

#167507

On 8/29/22 21:46, Thiago Adams wrote:
> On Monday, August 29, 2022 at 10:15:45 PM UTC-3, Thiago Adams wrote:
> ..> One "problem" with camel case is that c functions like fopen etc..
>> does not follow the rule resulting in a mixed style.
> 
> if we try to follow the existing c style..then we have more than one style
> > [snip]
 >
> typedef is sometimes upper
> 
> typedef /* unspecified */ FILE;

I believe i saw somewhere that `FILE` and `DIR` in particular came about 
as capitalized because, in the old Unix systems that the C standard and 
POSIX are based upon, they were defined as macros instead of typedefs 
(for some reason?), and standard practice was that macros are in 
screaming case.  Unfortunately, i don't remember where i saw this, so i 
don't have any sort of citation.
​
-- 
/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]

#167511

Blue-Maned_Hawk <bluemanedhawk@example.invalid> writes:

> On 8/29/22 21:46, Thiago Adams wrote:
>> On Monday, August 29, 2022 at 10:15:45 PM UTC-3, Thiago Adams wrote:
>> ..> One "problem" with camel case is that c functions like fopen etc..
>>> does not follow the rule resulting in a mixed style.
>> if we try to follow the existing c style..then we have more than one style
>> > [snip]
>>
>> typedef is sometimes upper
>> typedef /* unspecified */ FILE;
>
> I believe i saw somewhere that `FILE` and `DIR` in particular came
> about as capitalized because, in the old Unix systems that the C
> standard and POSIX are based upon, they were defined as macros instead
> of typedefs (for some reason?), and standard practice was that macros
> are in screaming case.

C was developed over the course of a few years as a working language and
FILE was needed and defined before the language had typedef.

-- 
Ben.

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

#167519

Blue-Maned_Hawk <bluemanedhawk@example.invalid> writes:
> On 8/29/22 21:46, Thiago Adams wrote:
>> On Monday, August 29, 2022 at 10:15:45 PM UTC-3, Thiago Adams wrote:
>> ..> One "problem" with camel case is that c functions like fopen etc..
>>> does not follow the rule resulting in a mixed style.
>> if we try to follow the existing c style..then we have more than one
>> style
>> > [snip]
>>
>> typedef is sometimes upper
>> typedef /* unspecified */ FILE;
>
> I believe i saw somewhere that `FILE` and `DIR` in particular came
> about as capitalized because, in the old Unix systems that the C
> standard and POSIX are based upon, they were defined as macros instead
> of typedefs (for some reason?), and standard practice was that macros
> are in screaming case.  Unfortunately, i don't remember where i saw
> this, so i don't have any sort of citation.

It's possible that FILE was invented before typedef was added to the
language, though I can't verify that.

typedef was a relatively late addition.  It's in K&R1 (1978), but isn't
mentioned in the 1975 C reference manual.  The 1975 manual doesn't
mention FILE, but it does mention the "C library", which included at
least printf() and putchar().

https://www.bell-labs.com/usr/dmr/www/cman.pdf

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#167318

Le 30/08/2022 à 03:15, Thiago Adams a écrit :
> On Monday, August 29, 2022 at 3:07:10 PM UTC-3, Opus wrote:
>> Le 29/08/2022 à 18:02, Thiago Adams a écrit :
>>> On Saturday, August 27, 2022 at 8:06:12 PM UTC-3, 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
>>>
>>> NASA C Style
>>>  From August 1, 1994
>>> https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf
>> That's interesting. Turns out there's a lot in there that closely
>> matches my own style. Except for the naming convention! For which I do
>> favor CamelCase for all identifiers, and as the Window_SetText() example
>> you gave, I also use underscores to indicate hierarchical structure.
>>
>> And for types, I suffix them with '_t' as the C standard does.
> 
> One "problem" with camel case is that c functions like fopen etc..
> does not follow the rule resulting in a mixed style.

I know! But even the C std uses a mixed style. So...

I find it best to pick what works for you and be consistent about what 
*you* have an influence on, and just accept (or reject if you can) the 
rest. If anything here, having a clearly different style immediately 
shows what part of the code is yours and what isn't.

Inconsistency within a development team is a problem and then that's the 
job of managers to deal with it. But some inconsistency between your 
style and whatever styles have piled up in the C std over 33 years (or 
50 if you count C's legacy since its inception), I'm not too worried 
about it. Pick your battles. :)

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

#167308

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

> On Saturday, August 27, 2022 at 8:06:12 PM UTC-3, 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
>
> NASA  C Style
> From August 1, 1994 
> https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf

Blimey!  Not an impressive work by any means.  Full of errors (ok,
probably minor ones, but even so...).  Uses K&R syntax in places.  In
one place the examples have been updated to C90, but the text still
talks about K&R syntax.

Oh, I've now read some more and it's truly dreadful.  I'd list some of
the issues but there are so many it's just better to forget the whole
thing.

-- 
Ben.

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

#167351

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.

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

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

#167363

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

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

#167376

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

-- 
Ben.

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

#167377

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" ?

-- 
Lew Pitcher
"In Skills, We Trust"

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

#167378

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" ?

The same thing that happens when strcmp dereferences pX->email when
pX == NULL.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web