Имена функций в C++: Использовать для своей выгоды или нет? [закрытый]

Большинство кодов, которые я видел, - это функции camelCase (начальная буква нижнего регистра) и имена классов ProperCase / PascalCase и (обычно) , snake_case переменные.

Но, честно говоря, это всего лишь руководство. Самое важное - это согласованность всей базы кода. Выберите то, что кажется вам естественным / работает для вас, и придерживайтесь этого. Если вы присоединяетесь к незавершенному проекту, следуйте их стандартам.

Наиболее распространенными из них, которые я вижу в производственном коде, являются (в этом порядке):

myFunctionName     // lower camel case

MyFunctionName     // upper camel case

my_function_name   // K & R ?

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

Например, бывшие программисты Java обычно используют нижний регистр для функций

Если вы посмотрите на стандартные библиотеки , то обычно увидите, что это my_function , но у каждого человека, похоже, свой путь: - /

Я думаю, что это вопрос предпочтений, хотя я предпочитаю myFunction (...)

Как говорили другие, в C ++ такого нет. Сказав это, я предпочитаю использовать стиль, в котором написана стандартная библиотека - K&R.

Кроме того, см. Запись в FAQ Бьярна Страуструпа .

Делайте, что хотите, при условии, что вы согласны со своими разработчиками. группа. каждые несколько лет правила меняются ..... (remmeber nIntVAr) ...

Все зависит от вашего определения правильности. Есть много способов оценить свой стиль кодирования. Читаемость важна (для меня). Вот почему я бы использовал способ my_function для написания имен функций и имен переменных.

Не так уж много "правильного" языка. Это более личные предпочтения или стандарт для вашей команды. Обычно я использую myFunction (), когда пишу свой собственный код. Кроме того, стиль, о котором вы не упомянули и который часто встретите в C ++, - это my_function () - без заглавных букв, подчеркивания вместо пробелов.

На самом деле он просто продиктован кодом, в котором вы работаете. Или, если это ваш собственный проект, тогда ваши личные предпочтения.

Лично я предпочитаю thisStyle ThisStyle для функций. Это действительно для личного вкуса, вероятно, под влиянием Java, но мне очень нравится, чтобы функции и классы выглядели иначе.

Если бы мне пришлось спорить с этим, я бы сказал, что это различие немного больше, чем просто эстетическое. Это избавляет вас от лишних мыслей, когда вы сталкиваетесь с конструкцией временного объекта в функциональном стиле. Напротив, вы можете возразить, что на самом деле не имеет значения, является ли Foo (1,2,3) вызовом функции или нет - если это конструктор, то он действует точно так же, как функция, возвращающая В любом случае Foo по значению.

Соглашение также избегает фиаско с функцией с тем же именем, что и класс-не-ошибка, которое наследует C ++, потому что C имеет отдельное пространство имен тегов:

#include <iostream>

struct Bar {
    int a;
    Bar() : a(0) {}
    Bar(int a) : a(a) {}
};

struct Foo {
    Bar b;
};

int Bar() {
    return 23;
}

int main() {
    Foo f;
    f.b = Bar();
    // outputs 23
    std::cout << f.b.a << "\n";
    // This line doesn't compile. The function has hidden the class.
    // Bar b;
}

Bar в конце концов, как существительное, так и глагол, поэтому их можно разумно определить как класс в одном месте и функцию в другом. Очевидно, есть лучшие способы избежать столкновения, например, правильное использование пространств имен. Итак, как я сказал, на самом деле это просто потому, что я предпочитаю внешний вид функций с инициалами в нижнем регистре, а не потому, что на самом деле необходимо отличать их от классов.

В отличие от Java, C ++ не имеет «стандартного стиля». Практически вся компания, в которой я когда-либо работал, имеет свой собственный стиль программирования на C ++, и большинство проектов с открытым исходным кодом также имеют свои собственные стили. Несколько соглашений по кодированию, на которые вы, возможно, захотите обратить внимание:

• Стандарты кодирования GNU (в основном C, но упоминается C ++)
• Руководство по стилю Google C ++
• Стандарты кодирования C ++: 101 правила, рекомендации и лучшие практики

Интересно отметить, что стандарты кодирования C ++ часто указывают, какие части языка не следует использовать . Например, в Руководстве по стилю Google C ++ сказано: «Мы не используем исключения C ++». Практически везде, где я работал, запрещены определенные части C ++. (Одно место, где я работал, в основном говорило: «Программируйте на C, но new и delete в порядке»!