C 中最常见的命名约定是什么？

Question

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)

Answer 1

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

Answer 2

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

Answer 3

You know, I like to keep it simple, but clear... So here's what I use, in C:

• Trivial Variables : i,n,c ,etc... (Only one letter. If one letter isn't clear, then make it a Local Variable)
• Local Variables : camelCase
• Global Variables : g_camelCase
• Const Variables : ALL_CAPS
• Pointer Variables : add a p_ to the prefix. For global variables it would be gp_var , for local variables p_var , for const variables p_VAR . If far pointers are used then use an fp_ instead of p_ .
• Structs : ModulePascalCase (Module = full module name, or a 2-3 letter abbreviation, but still in PascalCase .)
• Struct Member Variables : camelCase
• Enums : ModulePascalCase
• Enum Values : ALL_CAPS
• Public Functions : ModulePascalCase
• Private Functions : PascalCase
• Macros : PascalCase

I typedef my structs, but use the same name for both the tag and the typedef. The tag is not meant to be commonly used. Instead it's preferrable to use the typedef. I also forward declare the typedef in the public module header for encapsulation and so that I can use the typedef'd name in the definition.

Full struct Example :

typdef struct UtilsExampleStruct UtilsExampleStruct;
struct UtilsExampleStruct{
    int var;
    UtilsExampleStruct *p_link;
};

Answer 4

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

Answer 5

Coding in C#, java, C, C++ and objective C at the same time, I've adopted a very simple and clear naming convention to simplify my life.

First of all, it relies on the power of modern IDEs (such as eclipse, Xcode...), with the possibility to get fast information by hovering or ctrl click... Accepting that, I suppressed the use of any prefix, suffix and other markers that are simply given by the IDE.

Then, the convention:

• Any names MUST be a readable sentence explaining what you have. Like "this is my convention".
• Then, 4 methods to get a convention out of a sentence:
  1. THIS_IS_MY_CONVENTION for macros, enum members
  2. ThisIsMyConvention for file name, object name (class, struct, enum, union...), function name, method name, typedef
  3. this_is_my_convention global and local variables,
     parameters, struct and union elements
  4. thisismyconvention [optional] very local and temporary variables (such like a for() loop index)

And that's it.

It gives

class MyClass {
    enum TheEnumeration {
        FIRST_ELEMENT,
        SECOND_ELEMENT,
    }

    int class_variable;

    int MyMethod(int first_param, int second_parameter) {
        int local_variable;
        TheEnumeration local_enum;
        for(int myindex=0, myindex<class_variable, myindex++) {
             localEnum = FIRST_ELEMENT;
        }
    }
}

Answer 6

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.

Answer 7

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[]

Answer 8

You should also think about the order of the words to make the auto name completion easier.

A good practice: library name + module name + action + subject

If a part is not relevant just skip it, but at least a module name and an action always should be presented.

Examples:

• function name: os_task_set_prio , list_get_size , avg_get
• define (here usually no action part): OS_TASK_PRIO_MAX

Answer 9

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.

Answer 10

There could be many, mainly IDEs dictate some trends and C++ conventions are also pushing. For C commonly:

• UNDERSCORED_UPPER_CASE (macro definitions, constants, enum members)
• underscored_lower_case (variables, functions)
• CamelCase (custom types: structs, enums, unions)
• uncappedCamelCase (oppa Java style)
• UnderScored_CamelCase (variables, functions under kind of namespaces)

Hungarian notation for globals are fine but not for types. And even for trivial names, please use at least two characters.

Answer 11

When I will program in CI will use this convention:

definitions	prefix	examples
variables - local (trivial)	/	i , n , a , b ... ii , nn , aa , bb ... iii , nnn , aaa , bbb ...
variable - local (descriptive)	/	variable , conection ...
variable - global	g_	g_variable , g_connection ...
variable - constant	c_	c_variable , c_connection ...
pointer	p_	p_variable , p_connection ...
array	a_	a_variable , a_connection ...
struct	s_	s_variable , s_connection ...
union	u_	u_variable , u_connection ...
enum	e_	e_variables , e_connection ...
struct (member) union (member) enum (member)	m_ m_ m_	m_variable , m_connection ... m_variable , m_connection ... m_variable , m_connection ...
struct (bit field)	b_	b_variable , b_connection ...
function	f_	f_variable , f_connection ...
macro	o_	o_variable , o_connection ...

Note:

Each definition except variables has a single letter prefix, so that they can be combined and then not being miss understood.

Note:

Because I ran out of letters and I insisted to have only lower case letter prefixes, prefix " o_ " used for macro does not match the first letter of the definition ( m acro) but it matches the last letter (macr o ).

If you have any suggestions I am open minded.

Answer 12

I recommend you to read this document.

Abstract
This document is an updated version of the Indian Hill C Style and Coding Standards paper, with modifications by the last three authors. It describes a recommended coding standard for C programs. The scope is coding style, not functional organization.

https://www.doc.ic.ac.uk/lab/cplus/cstyle.html#N1026F

Answer 13

I think those can help for beginner: Naming convention of variables in c

1. You have to use Alphabetic Character (az, AZ), Digit (0-9) and Under Score (_). It's not allow to use any special Character like: %, $, #, @ etc. So, you can use user_name as variable but cannot use user&name .
2. Can not use white space between words. So, you can use user_name or username or username as variable but cannot use user name .
3. Can not start naming with digit. So, you can use user1 or user2 as variable but cannot use 1user .
4. It is case sensitive language. Uppercase and lowercase are significant. If you use a variable like username then you cannot use USERNAME or Username for father use.
5. You can not use any keyword (char, int, if, for, while etc) for variable declaration.
6. ANSI standard recognizes a length of 31 characters for a variable name