Почему стиль кодирования STL/Boost С++ сильно отличается от всех elses?

Я довольно программист на С++ новичок, но в своем ограниченном опыте с языком большинство стандартных правил стиля С++ (например, Руководства по стилю Google С++) идут против того, что реализовано в библиотеках stl и boost.

Например, имена классов в стандартной библиотеке С++ и Boost всегда имеют строчный регистр с подчеркиванием, разделяющим слова (например, std::vector, boost::unordered_map, std::map::const_iterator), тогда как большинство руководств по стилям, которые я видел для С++, имеют тенденцию к стилю CamelCase (например, TcpConnection или Int32).

То же самое относится и к методам. Стандартная библиотека и Boost используют тот же стиль для методов и функций, что и для классов (например, std::map<>::get_equal("foo")), тогда как большинство руководств по стилям выступают за pascalCase или CamelCase.

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

Кто-нибудь знает, почему это?

EDIT: просто для уточнения, я говорю просто о поверхностном текстовом стиле (обложка, использование подчеркиваний и т.д.), а не о фактическом стиле реализации.

ОТВЕТЫ

Ответ 1

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

Вот ссылка на его FAQ, где он обсуждает эту тему:

http://www.stroustrup.com/bs_faq2.html#Hungarian

Фрагмент, объясняющий, что вас интересует в частности:

Я предпочитаю использовать символы подчеркивания для разделения слов в идентификаторе (например, element_count), а не на альтернативы, например elementCount и ElementCount. Никогда не используйте имена со всей заглавной буквой (например, BEGIN_TRANSACTION), потому что это условно зарезервировано для макросов. Даже если вы не используете макросы, кто-то может засорить ваши файлы заголовков ими. Используйте начальную заглавную букву для типов (например, Square и Graph). Язык С++ и стандартная библиотека не используют заглавные буквы, поэтому вместо int и string, а не для String. Таким образом, вы можете распознавать стандартные типы.

Ответ 2

Существует хорошая причина для Бьярне Страуструп. При использовании функторов вы хотите, чтобы они выглядели как функции.

Но с помощью руководств по стилям CamelCase вы выделяете классы из методов и функций, используя Capitals в первом char имени классов и LowerCase в первом char метода.

Это не согласуется с программированием стиля алгоритма С++. Поскольку нет смысла отличать функтор от функции, предпочтительнее использовать стили кодирования С++ и stl, если вы хотите использовать функторы (и обычно вы хотите).

Ответ 3

Единственные правила, которые действительно необходимы, - это те, которые предназначены для предотвращения известных проблем:

  • Используйте ALL_CAPS (плюс символы подчеркивания и цифры) для имен препроцессора и только для имен препроцессора. Это может быть жестким преследованием проблем, вызванных столкновениями между (предположительно) не-препроцессорным идентификатором и именем препроцессора, еще более жестким, чтобы исправить их.
  • Никогда не начинайте идентификатор с символа подчеркивания и не имеете двойного подчеркивания где-либо внутри идентификатора. Они зарезервированы для реализации.

Помимо этого, будьте последовательны и не слишком придирчивы. Стандарты кодирования должны помнить о правиле № 0: "Не потейте мелочи". Слишком много стандартов кодирования потеют мелкие вещи.

Что касается стандарта Google С++, это не самое лучшее. Это больше, чем стандарт плюс или минус. Например, он запрещает пропускать непостоянную ссылку.