views:

411

answers:

6

Hi,

What are the naming conventions commonly use in C? I know there are at least two:

  1. GNU / linux / K&R with lower_case_functions
  2. ? name ? with UpperCaseFoo functions

I am talking about C only here. Most of our projects are small embedded systems in which we use C.

Here is the one I am planning on using for my next project:


C Naming Convention

Struct   TitleCase
Struct Members  lower_case or lowerCase

Enum     ETitleCase
Enum Members    ALL_CAPS or lowerCase

Public functions    pfx_TitleCase (pfx = two or three letter module prefix)
Private functions   TitleCase
Trivial variables   i,x,n,f etc...
Local variables lower_case or lowerCase
Global variables    g_lowerCase or g_lower_case (searchable by g_ prefix)
+5  A: 

"Struct pointers" aren't entities that need a naming convention clause to cover them. They're just struct WhatEver *. DON'T hide the fact that there is a pointer involved with a clever and "obvious" typedef. It serves no purpose, is longer to type, and destroys the balance between declaration and access.

unwind
+1 for the "don't hide pointers" stuff - even though this answer doesn't address much of the rest of the question (yet).
Jonathan Leffler
@unwind, I tend to agree. However, sometimes a pointer is not intended to be external dereferenced and it is more of a handle to the consumer than an actual pointer to a struct they will be using. Thats what I left the TitleCasePtr for. typedef struct { fields } MyStruct, *MyStructPtr;
JeffV
I am removing the TitleCasePtr, it is distracting from the actual question.
JeffV
+4  A: 

Well firstly C doesn't have public/private/virtual functions. That's C++ and it has different conventions. In C typically you have:

  • Constants in ALL_CAPS
  • Underscores to delimit words in structs or function names, hardly ever do you see camel case in C;
  • structs, typedefs, unions, members (of unions and structs) and enum values typically are in lower case (in my experience) rather than the C++/Java/C#/etc convention of making the first letter a capital but I guess it's possible in C too.

C++ is more complex. I've seen a real mix here. Camel case for class names or lowercase+underscores (camel case is more common in my experience). Structs are used rarely (and typically because a library requires them, otherwise you'd use classes).

cletus
@cletus, I realize that. By private I mean functions that are not exposed externally in the module header and are not intended to be used by code external to the module.Public would be module API functions intended to be used externally.
JeffV
You could regard static functions as private; the question doesn't mention virtual. But +1 for 'seldom see camel-case in C'.
Jonathan Leffler
I think Jeff meant `external linkage` for "public functions" and `internal linkage` for "private functions".
pmg
@pmg, exactly, thanks!
JeffV
I've seen constants starting with a k as well as in: kBufferSize. Not sure where that comes from.
JeffV
cletus is referring to #define constants. They should always be ALL_CAPS.
jmucchiello
Like I said, I've seen the use of kTitleCase style with defined constants. I preffer ALL_CAPS too, though.
JeffV
`ALL_CAPS` is often used for enum values, too.
caf
+3  A: 

I would recommend against mixing camel case and underscore separation (like you proposed for struct members). This is confusing. You'd think, hey I have get_length so I should probably have make_subset and then you find out it's actually makeSubset. Use the principle of least astonishment, and be consistent.

I do find CamelCase useful to type names, like structs, typedefs and enums. That's about all, though. For all the rest (function names, struct member names, etc.) I use underscore_separation.

Eli Bendersky
Yes, the main thing about any naming convention is predictability and consistency. Also, because the C library itself using all lowercase with _ for spacing, I would recommend using that just so you don't have to deal with 2 different naming conventions in a project(assuming you don't write a wrapper around libc to make it conform to your naming.. but thats gross)
Earlz
It also uses typedefs with an "_t" on the end, but I don't see anyone recommending that. In fact, the standard library is even inconsistent: div_t (stdlib.h) is a struct and so is tm (time.h). Also, take a look at the tm struct members, they all are prefixed with tm_ which seems pointless and ugly (IMO).
JeffV
+4  A: 

The most important thing here is consistency. That said, I follow the GTK+ coding convention, which can be summarized as follows:

  1. All macros and constants in caps: MAX_BUFFER_SIZE, TRACKING_ID_PREFIX.
  2. Struct names and typedef's in camelcase: GtkWidget, TrackingOrder.
  3. Functions that operate on structs: classic C style: gtk_widget_show(), tracking_order_process().
  4. Pointers: nothing fancy here: GtkWidget *foo, TrackingOrder *bar.
  5. Global variables: just don't use global variables. They are evil.
  6. Functions that are there, but shouldn't be called directly, or have obscure uses, or whatever: one or more underscores at the beginning: _refrobnicate_data_tables(), _destroy_cache().
axel_c
A: 

I'm confused by one thing: You're planning to create a new naming convention for a new project. Generally you should have a naming convention that is company- or team-wide. If you already have projects that have any form of naming convention, you should not change the convention for a new project. If the convention above is just codification of your existing practices, then you are golden. The more it differs from existing de facto standards the harder it will be to gain mindshare in the new standard.

About the only suggestion I would add is I've taken a liking to _t at the end of types in the style of uint32_t and size_t. It's very C-ish to me although some might complain it's just "reverse" Hungarian.

jmucchiello
Well, the conventions here are all over the place and inconsistent which is why I am setting out to document one. Also, it is why I am asking. To see what the community consensus is.
JeffV
I understand that pain. But there must be some subset of your existing conventions that is most popular. You should start there and not on a random Internet web page. Also you should ask your other devs what they would consider good.
jmucchiello
I believe type names ending in _t are reserved by the POSIX standard.
caf
uint32_t is a POSIX type?
jmucchiello
A: 

Here's an (apparently) uncommon one, which I've found useful: module name in CamelCase, then an underscore, then function or file-scope name in CamelCase. So for example:

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]
Steve Melnikoff