Как согласовать общие соглашения о присвоении имен C ++ с соглашениями библиотек?

Question

Большинство соглашений о присвоении имен в C ++ диктуют использование camelCaseIdentifiers: имена, начинающиеся с заглавной буквы для классов (Person, Booking), и имена, начинающиеся со строчной буквы для полей и переменных (getPrice(), isValid(), largestValue). Эти рекомендации полностью расходятся с соглашениями об именах библиотеки C ++, которые включают строчные имена для классов (string, set, map, fstream) и names_joined_with_an_underscore для методов и полей (find_first_of , lower_bound, reverse_iterator, first_type). Еще более усложняют картину функции операционной системы и библиотеки C, которые включают сжатые строчные имена в C и Unix и функции, начинающиеся с заглавной буквы в Windows.

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

Итак, как вы согласовываете эти разрозненные соглашения об именах?

Answer 1

Диомидис, я разделяю вашу боль и много лет тратил на переключение между различными схемами, пытаясь найти что-то, что работает с различными библиотеками / средами, которые я использую (MFC и / или STL / Boost). При работе с одной платформой, такой как STL, вы можете попытаться скопировать соглашение об именах, которое оно использует, но когда вы вводите другую платформу, она легко распадается.

В конце я принял единый стиль для всего нового кода, который я пишу (на основе рекомендаций по стилю Google C ++), и я реорганизую старый код, чтобы использовать этот стиль, когда это необходимо. Вы не можете легко согласовать различные соглашения об именах, поэтому не тратьте время на попытки. Примените схему для вашей команды / отдела / компании и придерживайтесь ее, но не зацикливайтесь на том, как «некрасивый» код может выглядеть при использовании комбинации схем.

Рекомендации Google C ++ довольно хороши, ИМХО, с некоторыми незначительными поправками. Проверьте руководство здесь:

http://google -styleguide.googlecode.com / SVN / багажник / cppguide.xml

Answer 2

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

Я медленно вижу, как эти соглашения переходят в рабочий код, но это битва против соглашений о присвоении имен MFC, которые все еще преобладают во многих местах.

Другие различия в стиле, которые борются со старыми стандартами, используют заключительные подчеркивания вместо m_ для обозначения членов.

Answer 3

Зачем нужно мириться? Пока код компилируется, и вы можете выполнять работу, не беспокойтесь об этом.

Answer 4

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

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

Answer 5

Честно говоря, я бы просто использовал библиотеку как есть и придерживался собственного стиля кодирования. Вы можете обернуть его, но это кажется излишним.

Answer 6

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

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

Answer 7

Кажется, я вспомнил, как давно читал, что они намеренно делают стандартную библиотеку отличной от рекомендуемого соглашения о кодировании, чтобы избежать коллизий имен. Однако я не могу найти никаких ссылок, которые упоминают об этом сейчас. Я помню, что читал, что вы не должны использовать начальные строчные буквы в именах типов, потому что они были зарезервированы для стандартных библиотек. Я предполагаю, что нечто подобное происходит с использованием подчеркивания. Я действительно не рассматриваю несколько соглашений об именах как проблему, поскольку они четко отделяют стандартный код от кода в вашем проекте. Я всегда кодирую вещи в своих проектах, используя заглавные буквы для типов и строчные буквы для методов / членов. На моем нынешнем рабочем месте в дополнение к типам используются заглавные буквы, что меня очень раздражает. Но им также нравятся венгерские бородавки, от которых отреклись даже MS: P

Answer 8

Ну, поскольку мы не можем изменить способ реализации стандартных библиотек, я думаю, нам придется с этим смириться. Что касается согласования - когда я некоторое время назад писал некоторые вещи для Win32 API, я пытался назвать свои собственные методы в PascalCasing, как это было сделано в API, но это было не совсем правильно. Поэтому я вернулся к названию своих методов в camelCase. Я согласен, что это беспорядок, но другой вариант - адаптировать ваш стиль к каждой новой фреймворке или библиотеке, которую вы используете, и есть проблема, о которой вы упомянули, когда несколько библиотек используют разные соглашения в одном проекте. Поэтому мой совет - придерживайтесь того, что кажется правильным для ваших собственных методов и занятий. Или - в корпоративной среде - придерживайтесь лучших практик и рекомендаций вашей компании.

Answer 9

Любимая цитата ::

Лучшее в стандартах то, что Есть так много на выбор!

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

Answer 10

Вы должны принять разницу.

Когда люди увидят использование remove_copy_if, они сразу узнают, что это алгоритм. На самом деле это положительная особенность, поскольку алгоритмы имеют определенные гарантии (или их отсутствие).

Мы также используем соглашение об именах для наших собственных пользовательских алгоритмов.