Каковы предпочтительные соглашения об именах для C++?
Я очень сбит с толку, глядя на библиотеку boost и stl, а затем на примеры людей. Кажется, что имена типов с заглавной буквы чередуются со всеми строчными буквами, разделенными подчеркиванием.
Что именно нужно делать в наши дни? Я знаю, что мир .NET имеет свой собственный набор соглашений, но, похоже, он полностью отличается от сферы C++.
Ответы 4
Какую банку с червями вы открыли.
Стандартная библиотека C++ использует underscore_notation для всего, потому что это то, что использует стандартная библиотека C.
Поэтому, если вы хотите, чтобы ваш код выглядел единообразно по всем направлениям (и на самом деле не использовал внешние библиотеки), это единственный выход.
Вы увидите, что boost использует ту же нотацию, потому что часто их библиотеки рассматриваются для будущих стандартов.
Помимо этого, существует множество соглашений, обычно использующих разные обозначения для обозначения разных типов символов. Обычно CamelCase используется для пользовательских типов, таких как классы и определения типов, и смешанный случай для переменных, специально для различения этих двух, но это, конечно, не универсальный стандарт.
Также есть Венгерская нотация, который дополнительно различает определенные типы переменных, хотя простое упоминание этой фразы может вызвать враждебность со стороны некоторых кодеров.
Лучший ответ как хороший программист на C++ - принять любое соглашение, используемое в коде, в который вы погружаетесь.
@dribeas: Недавно я наткнулся на эту статью и согласен с вами. Мне пришлось отказаться от своей рефлекторной ненависти к любой венгерской нотации, основанной на разновидности систем.
@Harper: верно, но может быть полезна венгерская нотация настоящий: [[double mLengthOfFootballField = 109.7, umHumanHairGrowthPerDay = 400; ]] Вы можете обнаружить плохие выражения, смешивая префиксы: [[mpsDecentRate = ftAltitudeDelta / sTimeDelta; // <- плохо! ]]
Нет хорошего ответа. Если вы интегрируетесь с существующей кодовой базой, имеет смысл соответствовать их стилю. Если вы создаете новую кодовую базу, вы можете установить простые рекомендации.
Все будет по-разному в зависимости от библиотеки и организации.
Например, для создаваемой мной служебной библиотеки разработчика я включаю удобные модули-оболочки для различных соглашений в стиле соглашения. Так, например, модуль оболочки MFC использует нотацию m_typeMemberVariable для членов, тогда как модуль оболочки STL использует member_variable. Я пытаюсь построить его так, чтобы любой используемый интерфейс имел стиль, типичный для этого типа интерфейса.
Проблема с универсальным стилем состоит в том, что все должны согласиться, и (например) для каждого человека, который ненавидит венгерскую нотацию, найдется кто-то, кто считает, что отказ от венгерской нотации умаляет основную ценность понятности кода. Поэтому маловероятно, что в ближайшее время появится универсальный стандарт для C++.
особенно после 20 с лишним лет "хотеть одного" :)
Найдите то, что вам удобно, и придерживайтесь этого. Некоторая форма стиля лучше, чем отсутствие стиля вообще, и не зацикливайтесь на том, как это делают другие библиотеки.
FWIW Я использую руководство по стилю Google C++ (с некоторыми настройками).
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Мне не нравится руководство по стилю Google C++ - оно рекомендует избегать таких функций, как исключения, что является просто ужасной практикой кодирования (конечно, это может быть одна из ваших модификаций, я не знаю)
Честно говоря, на самом деле рекомендую не избегает исключений. Он просто признает, что, поскольку у них есть кодовая база, небезопасная для исключений, их использование в новом коде будет дорогостоящим: «Скорее всего, все было бы иначе, если бы нам пришлось делать все заново с нуля».
Тем не менее, IMO можно постепенно преобразовать код, использующий исключения, в небезопасную кодовую базу, при условии, чтобы вы были дисциплинированы в отношении того, какие API-интерфейсы могут генерировать исключения, и вы предоставляете API-интерфейсы адаптера для исключения исключений, где это необходимо. Но я понимаю, почему ни одной компании может не понадобиться эта боль.
Я рекомендую прочитать о венгерской нотации. +1 к венгерской нотации приложений, -1 к системе венгерской нотации (посмотрим, смогу ли я убедить людей прочитать эту статью)