Каковы предпочтительные соглашения по именованию du jour для c ++?

Я совершенно сбит с толку, глядя на библиотеку boost и stl, а затем на примеры людей. Кажется, что имена типов с заглавными буквами чередуются со всеми строчными буквами, разделенными подчеркиванием.

Как именно все должно быть сделано в эти дни? Я знаю, что в мире .NET есть свой собственный набор соглашений, но он выглядит совершенно иначе, чем сфера C ++.

11.12.2008 22:10:43
4 ОТВЕТА

Какую банку с червями вы открыли.

Стандартная библиотека C ++ использует underscore_notation для всего, потому что это то, что использует стандартная библиотека C.

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

Вы увидите, что boost использует те же обозначения, потому что часто их библиотеки учитывают будущие стандарты.

Помимо этого, существует много соглашений, обычно использующих разные обозначения для обозначения различных типов символов. Обычно используется CamelCase для пользовательских типов, таких как классы и typedefs, и mixedCase для переменных, специально для различия этих двух типов , но это, безусловно, не универсальный стандарт.

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

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

9
11.12.2008 22:54:23
Я рекомендую прочитать о венгерской нотации. +1 к венгерской нотации приложений, -1 к системной венгерской нотации (посмотрим, смогу ли я привлечь людей к чтению статьи)
David Rodríguez - dribeas 11.12.2008 23:03:56
@ Dribeas: Я недавно наткнулся на эту статью, и я согласен с вами. Я должен был отучить свою рефлекторную ненависть к любой венгерской нотации, основанной на разнообразии систем.
Harper Shelby 11.12.2008 23:13:48
@Harper: правда, но могут пригодиться настоящие венгерские обозначения: [[double mLengthOfFootballField = 109.7, umHumanHairGrowthPerDay = 400; ]] Вы можете обнаружить неправильные выражения, смешивая префиксы: [[mpsDecentRate = ftAltitudeDelta / sTimeDelta; // <- плохо! ]]
Aaron 11.12.2008 23:24:45

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

Гугл есть .

2
11.12.2008 22:40:53

Это будет отличаться в зависимости от библиотеки и организации.

Например, для библиотеки утилит разработчика, которую я создаю, я включаю дружественные модули-обертки для различных соглашений в стиле соглашения. Так, например, модуль оболочки MFC использует нотацию m_typeMemberVariable для членов, тогда как модуль оболочки STL использует member_variable. Я пытаюсь сделать так, чтобы любой используемый интерфейс имел стиль, типичный для этого типа интерфейса.

Проблема с универсальным стилем заключается в том, что каждый должен был бы согласиться, и (например) для каждого человека, который ненавидит венгерскую нотацию, есть кто-то еще, кто думает, что не использование венгерской нотации умаляет основную ценность понятности кода. Так что вряд ли скоро будет универсальный стандарт для C ++.

0
11.12.2008 23:03:08
особенно после 20 с лишним лет "желающих" :)
baash05 11.12.2008 23:39:12

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

FWIW Я использую руководство по стилю Google C ++ (с некоторыми изменениями).

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

-1
12.12.2008 09:11:39
Мне не нравится руководство по стилю Google C ++ - оно рекомендует избегать таких функций, как исключения, что является просто ужасной практикой кодирования (да, это может быть одна из ваших модификаций, я не знаю)
coppro 12.12.2008 16:45:45
Чтобы быть справедливым, это действительно не рекомендует избегать исключений. Это просто признает, что, поскольку у них есть небезопасная кодовая база, начинать использовать их в новом коде было бы дорого: «Скорее всего, все было бы иначе, если бы нам пришлось делать это заново с нуля».
Steve Jessop 12.12.2008 19:42:03
Тем не менее, IMO можно постепенно преобразовывать код, использующий исключения, в небезопасную кодовую базу, при условии, что вы дисциплинированы в отношении того, какие API могут генерировать исключения, и при необходимости предоставляете API-интерфейсы для перехвата исключений. Но я понимаю, почему любая компания не хочет боли.
Steve Jessop 12.12.2008 19:45:31