Аббревиатуры и сокращения в именах должны записываться в нижнем регистре

Допускаются любые нарушения рекомендаций, если это улучшает читаемость.

Основная цель рекомендаций — улучшение читаемости и, следовательно, ясности и лёгкости поддержки, а также общего качества кода. Невозможно дать рекомендации на все случаи жизни, поэтому программист должен мыслить гибко.

Правила могут быть нарушены, если против них есть персональные возражения.

Это попытка создать набор общих рекомендаций, не навязывая всем единый стиль. Опытные программисты обычно всё равно подгоняют стиль под себя. Подобный список рекомендаций, имеющийся под рукой (или хотя бы требование ознакомиться с ним), обычно заставляет людей задумываться о стиле программирования и оценке их собственных практик в этой области.

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

Соглашения об именовании

 

Общие соглашения об именовании

3. Имена, представляющие типы, должны быть обязательно написаны в смешанном регистре, начиная с верхнего.

Line, SavingsAccount

Общая практика в сообществе разработчиков C++.

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

line, savingsAccount

Общая практика в сообществе разработчиков C++. Позволяет легко отличать переменные от типов, предотвращает потенциальные коллизии имён, например: Line line;

5. Именованные константы (включая значения перечислений) должны быть записаны в верхнем регистре с нижним подчёркиванием в качестве разделителя.

MAX_ITERATIONS, COLOR_RED, PI

Общая практика в сообществе разработчиков C++. Использование таких констант должно быть сведено к минимуму. В большинстве случаев реализация значения в виде метода — лучшее решение:

int getMaxIterations() // НЕЛЬЗЯ: MAX_ITERATIONS = 25

{

return 25;

}

Эта форма более читаемая и гарантирует единый интерфейс к значениям, хранящимся в классе.

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

getName(), computeTotalWidth()

Совпадает с правилом для переменных, но отличие между ними состоит в их специфических формах.

7. Названия пространств имён следует записывать в нижнем регистре.

model::analyzer, io::iomanager, common::math::geometry

Общая практика в сообществе разработчиков C++.

Следует называть имена типов в шаблонах одной заглавной буквой.

template<class T>...

template<class C, class D>...

Общая практика в сообществе разработчиков C++. Позволяет выделить имена шаблонов среди других используемых имён.

Аббревиатуры и сокращения в именах должны записываться в нижнем регистре.

exportHtmlSource(); // НЕЛЬЗЯ: exportHTMLSource();

openDvdPlayer(); // НЕЛЬЗЯ: openDVDPlayer();

Использование верхнего регистра может привести к конфликту имён, описанному выше. Иначе переменные бы имели имена dVD, hTML и т. д., что не является удобочитаемым. Другая проблема уже описана выше; когда имя связано с другим, читаемость снижается; слово, следующее за аббревиатурой, не выделяется так, как следовало бы.

10. Глобальные переменные всегда следует использовать с оператором разрешения области видимости (::).

::mainWindow.open(),::applicationContext.getName()

Следует избегать использования глобальных переменных. Предпочтительнее использование синглтонов.

11. Членам класса с модификатором private следует присваивать суффикс-подчёркивание.

class SomeClass {

private:

int length_;

}

Не считая имени и типа, область видимости — наиболее важное свойство переменной. Явное указание модификатора доступа в виде подчёркивания избавляет от путаницы между членами класса и локальными переменными. Это важно, поскольку переменные класса имеют большее значение, нежели переменные в методах, и к ним следует относиться более осторожно.

Дополнительным эффектом от суффикса-подчёркивания является разрешение проблемы именования в методах, устанавливающих значения, а также в конструкторах:

void setDepth (int depth)

{

depth_ = depth;

}

Проблема заключается в том, что существует два варианта подчёркивания — в виде суффикса и в виде префикса. Оба варианта широко используются, но рекомендуется именно первый вариант, потому что он обеспечивает лучшую читаемость. Следует отметить, что определение модификатора доступа у переменных — иногда спорный вопрос. Хотя кажется, что рекомендуемая практика набирает сторонников и становится всё более распространённой в среде профессионалов.