isFollowingCamelCaseConventionInCPlusPlus more_import_than_readability?

Question

Я возвращаюсь с Python на C ++ для моего следующего проекта.
Я знаю , почему я не должен , и я знаю , почему я должен . Не берите в голову эту дискуссию.

Соглашение C ++ ForVariablesIsCamelCase AndImHavingTrouble AcceptingIt as, at_least_for_my_eyes_it's_less_readable_than_the_lower_case_underscored_convention.

Кто-нибудь из вас сталкивался со статьей или информацией о том, что программисты должны принять соглашение lower_case_underscored и отказаться от camelCase, даже в проектах C ++? Или, может быть, исследование, которое показывает, что одно действительно научно более читабельно, чем другое?

Answer 1

Если кодирование в команде, последовательность, вероятно, важнее, чем личные предпочтения;Члены команды не должны переключаться между чтением кода Джо и чтением кода Джейн.Точно так же, если вы кодируете академические задания, следует придерживаться стиля курса, такого как командный стиль (правильно или неправильно), просто потому, что человек, присуждающий оценки, будет привыкнуть к этому чтению, и вам нужно будет извлечь максимально возможную оценку для вашей работы!

В противном случае я бы предположил, что одно соглашение имеет небольшое преимущество перед другим.CamelCase обеспечивает определенную эффективность длины символа.

Answer 2

Если это частный проект, используйте любое соглашение об именах, которое вам удобно и помогает вам быть продуктивным.Просто имейте в виду, что, как правило, хорошей идеей является соответствие общему «стилю» языка / обычной практики, поскольку любые образцы / примеры и т. Д. Обычно используют этот стиль, делая интеграцию и т. Д. Более легкой и менее «раздражающей»..

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

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

Одна вещь, которую я бы лично сказал о CamelCase, - это не зацикливаться на этом и применять здравый смыслради читабельности.Например, я часто видел аббревиатуры в именах падежей верблюда, написанных как верхняя часть / нижняя часть, что, как мне кажется, действительно ухудшает читабельность.В таких случаях я всегда выбирал более читаемый вариант.Так, например, я бы всегда писал:

private string targetURL;

, а не

private string targetUrl;

Но это всего лишь личные предпочтения.

Answer 3

CamelCase против подчеркиваний: научное вскрытие описывает одно научное исследование, которое нашло:

Рассматривая все четыре гипотезы вместе, становится очевидным, что стиль случая верблюда приводит к лучшему во всех отношениях, как только предмет обучается этому стилю. Требуется обучение, чтобы быстро распознать такой идентификатор.

Но тогда страница не соглашается с тем, что их выводы верны. :)

Он также имеет два опроса посетителей сайта, оба из которых 50/50 в пользу каждого стиля.

Answer 4

Не существует согласованного соглашения для именования C ++ среди программистов C ++, однако строчная буква с подчеркиванием используется как в стандартной библиотеке C ++, так и в boost.

---

Что касается документа стандартов кодирования, который вы связали...

Ссылка на случайные стандарты кодирования компании, которые используют "Общепринятую практику в сообществе разработчиков C ++" в качестве обоснования своих стандартов, но не приводят никаких ссылок на это утверждение, которые пахнут как ложное обращение к власти вДля того, чтобы оправдать предпочтения того, кто написал документ.