Comments 21
Нет. Теперь все переводы будут в этом подозревать? :-) На самом деле, вроде один остался.
Ну, если препод и дальше так будет работать со студентами, то конца не будет гугл-транслейт-статьям. В общем, успехов Вам.
Спасибо, мы бдим =) Думаю, в следующий сет мы уже поищем выход из ситуации.
Еще один перевод ( — да) студента ( — нет), чтобы сдать зачет ( — нет)?

Попадание 1 из 3-х.
Не Нострадамус :).
По какой причине пошла «мода» ставить константам префикс «k»? Я бы понял «с», но почему «k»?

Это идёт от так называемой венгерской нотации. В классической версии этой нотации префикс "c" использовался для char, а "k" — для констант.

Т.е. из-за того, что «с» уже было занято, взяли любую другую какую-то букву просто так, без великого аббревиатурного смысла?
Ну может потому, что «k» сама по себе произносится как «c» в слове «constant» :) А, может, потому, что Чарльз Симони был венгерского происхождения, а по-венгерски «константа» — это «konstans».
Во, вот такой вариант меня устраивает. Звёзды сошлись, я доволен:)

За работу над переводом спасибо. По сути статьи — рекомендации не содержат пояснения и причин рекомендации, а значит вслепую применять затруднительно, не понимая, в той же ситуации ты или нет.
Для себя определился со стилем — все нижним регистром кроме типов как аргументов шаблонов. Нет разделения на константы или переменные. Все поля объектов — без дополнительных декораций. Имена типов с суффиксом _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>
...

Такой подход во-первых более соответствует публичному интерфейсу стандартной библиотеки, во-вторых — помогает фокусироваться на алгоритме и функционале вместо отвлечения на сущность имени — поле, аргумент, константа. Алгоритму должно быть все равно, константность обеспечит ключевое слово в конст-корректном коде, поле — внутреннее состояние, которое не отличимо по природе от переменной для чистой реализации.
Венгерская нотация недостаточна и одновременно избыточна для современного кода с шаблонами, лямбдами и прочими сущностями, невыразимымы через вменяемое количество суффиксов и префиксов.

Пожалуйста.

Пояснений и причин не будет — это тема большого холивара. Сомнительно, что будет расписываться руководство с приглашением поспорить.

Для собственного стиля: вам своих правил хватает? Или хочется там добавить, потом ещё …?
Гугловое руковоство (полное, а не только именование) тем и хорошо, что сразу обо всём. И когда свои правила становятся тесноваты — Гугл уже идёт к вам.
Не хотелось бы работать с кодом, в котором типы отличаются от переменных лишь наличием смайлика со шрамом о_t.
Почему вы игнорируете такой важный элемент выделения символов как регистр?
Хорошо конечно, что у Google все подумано до мелочей, но напоминает это в какой-то степени Венгерскую нотацию, широко используемую в WinAPI (повсюду заклавные буквы и префиксы (в меньшей мере)). Продолжительное время разрабатываю в Linux, но те боль и мучения, связанные с разработкой в институте и в начале карьеры, еще отчетливо лежат в памяти.

Предполагаю, что нотация должа исходить от того, в каком фреймворке вы программируете или какие библиотеки используете. Если вы пишете в 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 и все поля в открытом доступе (понятно, что можно запретить. Но обычно — так)
классы — в них члены данных закрыты (типа так правильно), а для доступа есть функции.
Как результат — члены данных классов явно отличают от полей структур и функций.
Почему Гугл решил разделить именование функции классов и поля структур? Есть стайлгайды, где они именуются одинаково. Ну а у Гугла свои исторические предпосылки…
Only those users with full accounts are able to leave comments. Log in, please.