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

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

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

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

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

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

Рекомендации Google C ++ довольно хороши, IMHO - с небольшими поправками. Ознакомьтесь с руководством здесь:

https://google.github.io/styleguide/cppguide.html#Naming

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

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

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

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

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

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

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

Лучшее в стандартах - это то, что есть из чего выбирать!

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

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

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

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

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

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