Почему стиль кодирования STL / Boost C++ так сильно отличается от всех остальных? [закрытый]

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

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

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

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

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

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

3 61
c++ coding-style naming-conventions

3 ответа:

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

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

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

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

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

37

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

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

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

7

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

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

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

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

2