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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Тогда соглашение:

• Любые имена ДОЛЖНЫ быть читаемым предложением, объясняющим, что у вас есть. Как "это мое соглашение".
• Затем, 4 метода, чтобы получить условное выражение из предложения:
  • THIS_IS_MY_CONVENTION для макросов, членов перечисления
  • ThisIsMyConvention для имени файла, имени объекта (класса, структуры, перечисления, объединения...), имени функции, имени метода, typedef
  • this_is_my_convention глобальные и локальные переменные,
    параметры, структура и элементы объединения.
  • 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;
        }
    }
}

Ответ 6

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

Я нахожу CamelCase полезным для ввода имен, таких как structs, typedefs и enums. Это обо всем. Для всех остальных (имена функций, имена членов структуры и т.д.) Я использую underscore_separation.

Ответ 7

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

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

Ответ 8

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

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

Ответ 9

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

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

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

Примеры:

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

Ответ 10

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

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

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

Ответ 11

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

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