Комментарии 21
За работу над переводом спасибо. По сути статьи — рекомендации не содержат пояснения и причин рекомендации, а значит вслепую применять затруднительно, не понимая, в той же ситуации ты или нет.
Для себя определился со стилем — все нижним регистром кроме типов как аргументов шаблонов. Нет разделения на константы или переменные. Все поля объектов — без дополнительных декораций. Имена типов с суффиксом _t, шаблонные типы — с суффиксом _tt (от template type). Суффиксы помогают ориентировать код на строгую типизацию и облегчают тестирование.
...
class foo_tt{};
...
// production
using foo_t = foo_tt<bar_t>;
void run(foo_t foo);
....
// tests
using foo_t = foo_tt<mock::bar_t>
...Такой подход во-первых более соответствует публичному интерфейсу стандартной библиотеки, во-вторых — помогает фокусироваться на алгоритме и функционале вместо отвлечения на сущность имени — поле, аргумент, константа. Алгоритму должно быть все равно, константность обеспечит ключевое слово в конст-корректном коде, поле — внутреннее состояние, которое не отличимо по природе от переменной для чистой реализации.
Венгерская нотация недостаточна и одновременно избыточна для современного кода с шаблонами, лямбдами и прочими сущностями, невыразимымы через вменяемое количество суффиксов и префиксов.
Пояснений и причин не будет — это тема большого холивара. Сомнительно, что будет расписываться руководство с приглашением поспорить.
Для собственного стиля: вам своих правил хватает? Или хочется там добавить, потом ещё …?
Гугловое руковоство (полное, а не только именование) тем и хорошо, что сразу обо всём. И когда свои правила становятся тесноваты — Гугл уже идёт к вам.
Почему вы игнорируете такой важный элемент выделения символов как регистр?
Предполагаю, что нотация должа исходить от того, в каком фреймворке вы программируете или какие библиотеки используете. Если вы пишете в Qt — надо придерживаться стиля написания Qt. Если Modern C++ и Boost — Undescope. В последнем случае Google C++ Code Style выглядит совсем инородным.
Я бы давал вольности при разработке, ограничивая лишь базовые вещи: количество пробелов, наличие табов, расположение открывающейся и закрывающейся скобок. Все остальное от контекста. Если код на C — указатель пишем слитно с переменной, если на C++ — наоборот. Ну и так далее… А там настроить .clang-format под конкретный проект — занятие на 1-2 часа.
В начале статьи есть ссылка на обновляемый перевод и в нём уже переведено вступление с целями документа и другими рассуждениями общего характера.
Для отдельной статьи это маловато/скучновато, поэтому можно смотреть там.
Девочка с фотографии, похоже, слегка прифигела от прочитанного. Потому что даже она знает, что есть CppCoreGuidelines.
1. гайдов по стилю найти можно много. Какой выбрать — решает команда. Некоторые команды вообще пишут свой гайд. Если использовать «внешний» гайд, то желательно оценить его дополнительную полезность. Например, Google настоятельно рекомендует использовать свой гайд (логично, правда?) для проектов, интегрируемых с Гуглом. С другой стороны, Страуструп и Сеттер люди известные. С третьей, CppCoreGuidelines вроде бы никто стандартом не объявлял. Так что: на вкус и цвет все фломастеры разные…
2. чисто практический вопрос: Izvolov, так что там с переводом CppCoreGuidelines? Может займётесь?
Гугловские рекомендации тоже никто стандартом не объявлял. И не объявит. Чего только стоит идиотская рекомендация передавать выходные параметры функции по указателю.
Что касается перевода — не переживайте. Я свой посильный вклад в сообщество делаю. И вам предлагаю не тратить время на гугловское дерьмище, и если хочется заняться переводом, то переводить core guidelines.
А начать всегда можно с этого: https://translate.yandex.ru/translate?url=https%3A%2F%2Fgithub.com%2Fisocpp%2FCppCoreGuidelines%2Fblob%2Fmaster%2FCppCoreGuidelines.md&lang=en-ru
Мне лично привычнее добавлять впереди «m_», и сразу понятно, что у нас тут используется, простите, член.
Раньше был упор на тип данных. Отсюда венгерская нотация и m_. Причём m_ — половинчатый костыль (обычно к функциям не применяют).
Сейчас есть мощные IDE и пошла мода на «как применять» данные, функции и др.
Также стараются явно уйти от венгерской нотации.
Поэтому функции именуют одним образом, а члены данных — другим образом.
Отличие классов от структур связано, подозреваю, с историческим применением:
структуры — это «почти» POD и все поля в открытом доступе (понятно, что можно запретить. Но обычно — так)
классы — в них члены данных закрыты (типа так правильно), а для доступа есть функции.
Как результат — члены данных классов явно отличают от полей структур и функций.
Почему Гугл решил разделить именование функции классов и поля структур? Есть стайлгайды, где они именуются одинаково. Ну а у Гугла свои исторические предпосылки…
Руководство Google по стилю в C++. Часть 8