Существует ли хорошее / широко распространенное соглашение / стандарты кодирования шаблонов c ++? - PullRequest
3 голосов
/ 22 февраля 2011

Мне нравятся стандарты кодирования.При написании C ++ я люблю стандарты кодирования.Хороший стандарт кодирования добавляет контекст к языку, что немного затрудняет синтаксический анализ.

Существует несколько общепринятых стандартов, с которыми, я думаю, все, по крайней мере, немного знакомы:

  • Переменные-члены с префиксом 'm' или 'm _'
  • Префикс класса (обычно специфичный для проекта, т. Е. В Qt все имена классов имеют префикс «Q»)
  • Включить защитутакие соглашения, как "взять имя файла во всех заглавных буквах, заменить". "with '_' "
  • Правило трех

Существует множество маленьких правил C ++, подобных этому.К сожалению, мне никогда не удавалось найти подобные инструкции, касающиеся шаблонов.Я думаю, что самое популярное имя для аргумента шаблона - «T», но оно не имеет смысла, и если шаблон не очевиден, он может сделать код еще сложнее для чтения.

В любом случае, основная проблема у меня заключается в том, что шаблонытрудно читать, и я думаю, что некоторые соглашения могут быть использованы, чтобы их было легче читать.Кто-нибудь знает широко распространенное соглашение, облегчающее чтение шаблонного кода?

Ответы [ 6 ]

7 голосов
/ 22 февраля 2011

Просто добавляю зерно соли. Я думаю, что две самые важные библиотеки в мире программирования на C ++ - это библиотеки стандартных шаблонов и библиотеки повышения. Лично я стараюсь в основном соответствовать виду обозначений, который преобладает в этих библиотеках. Это разделенные подчеркиванием имена в нижнем регистре для классов, функций, членов данных, typedefs, перечислений и т. Д. И CamelCase (без подчеркивания) для аргументов шаблона. Как правило, вы также хотите иметь разумные имена для аргументов шаблона. Хорошей практикой является предоставление им названия концепции, которую они должны реализовывать (например, аргумент шаблона, который должен быть итератором, реализующим ForwardIteratorConcept, должен называться ForwardIterator).

Соглашения, которые вы упомянули («m» для членов и имена, начинающиеся с заглавных букв для классов), являются своего рода соглашением по чисто объектно-ориентированному программированию («чистый» подразумевается так: без каких-либо других парадигм программирования, таких как общее программирование или шаблонное метапрограммирование). Он в основном используется в Java (или «нативами» Java, которые программируют на C ++). Мне лично это не нравится, и я знаю мало людей, которые это делают Меня всегда немного раздражает работа в рамках фреймворка или проекта, который принимает эту нотацию, она противоречит стандартным библиотекам, расширенным библиотекам и общему правильному использованию пространств имен.

3 голосов
/ 22 февраля 2011

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

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

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

Тем не менее, есть два исключения для рассмотрения. Во-первых, если у вас уже есть большая кодовая база, следуйте тому, что там уже есть: сочетание стилей сбивает с толку. Во-вторых, есть отличные библиотеки, такие как Qt, которые не соответствуют стилю стандартных библиотек, они также достойны примерами стандартов кодирования.

2 голосов
/ 22 февраля 2011

Не существует «общих соглашений» для имен.Даже упомянутые вами соглашения не так распространены, как вы думаете.Я не могу представить, чтобы кто-то использовал префикс m или m_ для данных членов класса, кроме подмножества разработчиков Windows.Аналогично для префиксов имен классов.

Соглашения такого рода очень специфичны для проекта.Вы соглашаетесь с ними в проекте и двигаетесь дальше.Когда вы начинаете новый проект, совершенно нормально иметь новые соглашения, если вы того пожелаете.Если вам не хватает воображения или уверенности, чтобы выбрать свои собственные условности, купите книгу Херба Саттера и Андрея Александреску C ++ Coding Standards .Фактически, вы должны действительно прочитать его, потому что он имеет дело с гораздо более эффективными соглашениями, чем соглашения об именах.С вещами, которые действительно имеют значение.

Если это вообще помогает, я иногда вижу людей, выбирающих для параметров шаблона короткие имена, которые начинаются с заглавной буквы.Например, template<class Ch, class Tr>.Ищите вдохновение в стандартной библиотеке вашего компилятора.

2 голосов
/ 22 февраля 2011

* Переменные-члены с префиксом 'm' или 'm _'

Сомнительный.

* Префикс класса (обычно специфичный для проекта, т. Е. В Qt все имена классов имеют префикс «Q»)

Грозный. Была ли необходимая практика в тот день.

Большая тройка на самом деле не является стандартом и в значительной степени была заменена Большой Двойкой как хорошая практика (потому что использование RAII для указателей устраняет необходимость в деструкторе, даже когда вам нужны Копировать ctr и присваивание).

Во всяком случае ....

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

Конечно, если вы уже используете CamelCase для имен своих классов (Java-программисты - blech: p), вам следует использовать что-то еще.

Когда вы попадаете в сложные экземпляры и тому подобное, вам нужно использовать какой-то метод объявления ваших экземпляров шаблона в несколько строк. При метапрограммировании вам также часто нужно разбивать вещи на несколько строк и / или несколько типов / шаблонов. Это один из тех, кто учится по ходу дела. Мне нравится следующий метод:

template < typename MyParams >
struct my_metafunction
  : mpl::if_
    <
      check // probably wouldn't actually split this one since it's trivial...but as example...
      <
        MyParams
      >
    , some_type_expression
    , some_other_type_expression
    >
{};
0 голосов
/ 22 февраля 2011

Как говорят другие, это зависит от стиля кодирования проекта. Мне нравится использовать строчные буквы, разделенные знаком ниже при кодировании И для гармонии я использую строчные буквы для параметров шаблона. Чтобы отличить их от других, я начинаю с подчеркивания и заканчиваю "_t".

`

template<typename _encoder_t>
class compression
{
typedef typename _encoder_t::settings settings_t;
...
};

`

0 голосов
/ 22 февраля 2011

Посмотрите на Повышение , если хотите увидеть их соглашение о кодировании.

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