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

Какие соглашения об именах обычно используются в C? Я знаю, что их как минимум два:

1. GNU / linux / K&R с функциями lower_case_functions
2. ? название ? с функциями UpperCaseFoo

Я говорю только о C. Большинство наших проектов - это небольшие встроенные системы, в которых мы используем C.

Вот тот, который я планирую использовать в своем следующем проекте:

C Соглашение об именах

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)

Здесь самое главное - последовательность. Тем не менее, я следую соглашению о кодировании 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().

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

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

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

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

Знаете, мне нравится, когда это просто, но понятно ... Итак, вот что я использую в C:

• Тривиальные переменные : i,n,cи т. Д. (Только одна буква. Если одна буква непонятна, сделайте ее локальной переменной)
• Локальные переменные :lowerCamelCase
• Глобальные переменные :g_lowerCamelCase
• Постоянные переменные :ALL_CAPS
• Переменные указателя : добавьте p_к префиксу. Для глобальных переменных это будет gp_varдля локальных переменных p_var, для константных переменных p_VAR. Если используются дальние указатели, используйте fp_вместо p_.
• Структуры : ModuleCamelCase(Модуль = полное имя модуля или сокращение из 2–3 букв, но все еще внутри CamelCase.)
• Переменные элементов структуры :lowerCamelCase
• Перечисляет :ModuleCamelCase
• Значения перечисления :ALL_CAPS
• Публичные функции :ModuleCamelCase
• Частные функции :CamelCase
• Макросы :CamelCase

Я набираю свои структуры, но использую одно и то же имя как для тега, так и для typedef. Тег не предназначен для широкого использования. Вместо этого предпочтительнее использовать typedef. Я также передаю объявление typedef в заголовке общедоступного модуля для инкапсуляции, чтобы я мог использовать имя typedef'd в определении.

Полный struct пример :

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

Кодируя одновременно C #, java, C, C ++ и объект C , я принял очень простое и понятное соглашение об именах, чтобы упростить себе жизнь.

Прежде всего, он опирается на мощь современных IDE (таких как eclipse, Xcode ...), с возможностью быстро получать информацию, наведя курсор мыши или нажав ctrl ... Принимая это, я запретил использование любого префикса, суффикса и другие маркеры, которые просто выдаются IDE.

Затем соглашение:

• Любые имена ДОЛЖНЫ быть удобочитаемыми предложениями, объясняющими, что у вас есть. Типа «это моя конвенция».
• Затем 4 метода, позволяющие получить условность из предложения:
  1. THIS_IS_MY_CONVENTION для макросов, членов перечисления
  2. ThisIsMyConvention для имени файла, имени объекта (класс, структура, перечисление, объединение ...), имени функции, имени метода, typedef
  3. this_is_my_convention глобальные и локальные переменные,
     параметры, элементы структуры и объединения
  4. thisismyconvention [необязательно] очень локальные и временные переменные (например, индекс цикла for ())

И это все.

Это дает

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

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

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

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

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

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

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

Вы также должны подумать о порядке слов, чтобы упростить автоматическое завершение имени .

Хорошая практика: имя библиотеки + имя модуля + действие + тема

Если часть не актуальна, просто пропустите ее, но всегда должны быть представлены хотя бы имя модуля и действие.

Примеры:

• Имя функции: os_task_set_prio, list_get_size,avg_get
• define (здесь обычно нет части действия ):OS_TASK_PRIO_MAX

Их может быть много, в основном IDE диктуют некоторые тенденции, и соглашения C ++ также продвигаются. Для C обычно:

• UNDERSCORED_UPPER_CASE (определения макросов, константы, члены перечисления)
• underscored_lower_case (переменные, функции)
• CamelCase (настраиваемые типы: структуры, перечисления, объединения)
• uncappedCamelCase (стиль OPPA Java)
• UnderScored_CamelCase (переменные, функции в виде пространств имен)

Венгерская нотация для глобальных переменных подходит, но не для типов. И даже для банальных имен используйте хотя бы два символа.

Я думаю, это может помочь новичку: соглашение об именах переменных в c

1. Вы должны использовать алфавитный символ (az, AZ), цифру (0-9) и меньшую оценку (_). Нельзя использовать какие-либо специальные символы, такие как:%, $, #, @ и т. Д. Таким образом, вы можете использовать user_name как переменную, но не можете использовать user & name .
2. Нельзя использовать пробелы между словами. Таким образом, вы можете использовать user_name, или имя пользователя, или имя пользователя в качестве переменной, но не можете использовать имя пользователя .
3. Не могу начать именование с цифры. Таким образом, вы можете использовать user1 или user2 как переменную, но не можете использовать 1user .
4. Это язык с учетом регистра. Прописные и строчные буквы имеют значение. Если вы используете такую ​​переменную, как имя пользователя, вы не можете использовать ИМЯ ПОЛЬЗОВАТЕЛЯ или Имя пользователя для использования отцом.
5. Вы не можете использовать любое ключевое слово (char, int, if, for, while и т. Д.) Для объявления переменных.
6. Стандарт ANSI распознает длину 31 символа для имени переменной.