Каковы наиболее распространенные соглашения о присвоении имен в C?

«Указатели на структуры» не являются объектами, для которых требуется условие соглашения об именах. Это просто struct WhatEver * . НЕ скрывайте тот факт, что существует указатель, связанный с умным и "очевидным" typedef. Он бесполезен, больше предназначен для ввода и нарушает баланс между объявлением и доступом.

Во-первых, C не имеет публичных / частных / виртуальных функций. Это C ++, и у него другие соглашения. В C обычно у вас есть:

• Константы в ALL_CAPS
• Знаки подчеркивания для разделения слов в структурах или именах функций, вы почти никогда не увидите верблюжий регистр в C;
• структуры, определения типов, объединения, члены (объединений и структур ) и значения перечисления обычно записываются в нижнем регистре (по моему опыту), а не в соответствии с соглашением C ++ / Java / C # / и т. д. о превращении первой буквы в заглавную, но я думаю, что это возможно и в C.

C ++ более сложен. Я видел здесь настоящий микс. Верблюжий регистр для имен классов или строчные буквы + подчеркивания (по моему опыту чаще встречается верблюжий регистр). Структуры используются редко (и обычно потому, что они требуются библиотеке, иначе вы бы использовали классы).

Я бы не рекомендовал смешивать регистр верблюда и разделение подчеркивания (как вы предложили для членов структуры). Это смущает. Вы могли бы подумать: «Эй, у меня есть get_length , так что мне, вероятно, следовало бы иметь make_subset , а потом вы узнали, что это на самом деле makeSubset . Используйте принцип наименьшего удивления и будьте последовательны.

Я действительно считаю CamelCase полезным для ввода имен, таких как структуры, определения типов и перечисления. Но это все. Для всего остального (имена функций, имена членов структуры и т. Д.) Я использую underscore_separation.

Вот (по-видимому) необычный, который я нашел полезным: имя модуля в CamelCase, затем подчеркивание, затем имя функции или области видимости файла в CamelCase. Так, например:

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

Самое главное здесь - последовательность. Тем не менее, я придерживаюсь соглашения о кодировании GTK +, которое можно резюмировать следующим образом:

1. Все макросы и константы заглавными буквами: MAX_BUFFER_SIZE , TRACKING_ID_PREFIX .
2. Имена структур и typedef. в camelcase: GtkWidget , TrackingOrder .
3. Функции, работающие со структурами: классический стиль C: gtk_widget_show () , tracking_order_process () .
4. Указатели: здесь ничего особенного: GtkWidget * foo , TrackingOrder * bar .
5. Глобальные переменные: просто не используйте глобальные переменные. Они злы.
6. Функции, которые есть, но не следует вызывать напрямую или иметь неясное использование или что-то еще: одно или несколько подчеркивания в начале: _refrobnicate_data_tables () , _destroy_cache () .

Меня смущает одно: вы планируете создать новое соглашение об именах для нового проекта. Как правило, у вас должно быть соглашение об именах, которое распространяется на всю компанию или команду. Если у вас уже есть проекты, которые имеют какое-либо соглашение об именах, вам не следует менять соглашение для нового проекта. Если приведенное выше соглашение является просто кодификацией ваших существующих практик, тогда вы золотой. Чем больше он отличается от существующих де-факто стандартов, тем труднее будет привлечь внимание к новому стандарту.

Единственное, что я хотел бы добавить, это то, что мне понравился _t в конце типов в стиле uint32_t и size_t. Для меня это очень по-C-ишски, хотя некоторые могут пожаловаться, что это просто "обратный" венгерский язык.