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

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

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

инструкции по C++ Google довольно хороши, по моему скромному мнению - с некоторыми несущественными поправками. Проверьте руководство здесь:

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

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

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

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

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

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

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

Кавычка Fav::

лучшая вещь о стандартах состоит в том, что существуют так многие для выбора из!

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

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

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