Большинство соглашений об именовании С++ диктуют использование camelCaseIdentifiers: имен, начинающихся с прописной буквы для классов (Person, Booking) и имен, начинающихся с строчной буквы для полей и переменных (getPrice(), isValid(), largestValue). Эти рекомендации полностью противоречат соглашениям об именах библиотеки С++, которые включают имена нижних регистров для классов (string, set, map, fstream) и names_joined_with_an_underscore для методов и полей (find_first_of, lower_bound, reverse_iterator, first_type). Дальнейшее усложнение изображения - это операционная система и функции библиотеки C, которые включают сжатые имена нижнего регистра в C и Unix и функции, начинающиеся с буквы верхнего регистра в Windows.
В результате мой код беспорядок, потому что некоторые идентификаторы используют соглашение об именовании библиотеки С++, C или операционной системы, а другие используют предписанное соглашение С++. Написание классов или методов, которые обертывают функциональность библиотеки, болезненно, потому что заканчиваются именами разных типов для похожих вещей.
Итак, как вы соглашаетесь с этими разрозненными соглашениями об именах?
Один из способов принять С++ naming_convention, это то, что большинство примеров кода в литературе делают в настоящее время.
Я медленно вижу, что эти соглашения переходят в производственный код, но это битва против соглашений об именах MFC, которые по-прежнему преобладают во многих местах.
Другие отличия стиля, которые борются со старыми стандартами, используют трейлинг-символы подчеркивания, а не m_ для обозначения членов.
Diomidis, я разделяю вашу боль и много лет переходил между разными схемами, пытаясь найти что-то, что работает с различными библиотеками/фреймворками, которые я использую (MFC и/или STL/Boost). При работе с единой структурой, такой как STL, вы можете попробовать и скопировать соглашение об именах, которое оно использует, но когда вы вводите другую структуру, она легко разваливается.
В конце концов, я принял один стиль для всего нового кода, который я пишу (на основе принципов стиля Google С++), и я реорганизую старый код, чтобы использовать этот стиль, когда это необходимо. Вы не можете смириться с различными соглашениями об именах очень легко, так что не тратьте время на попытки. Соблюдайте схему своей команды/отдела/компании и придерживайтесь ее, но не зацикливайтесь на том, как "уродливый" код может выглядеть при использовании комбинации схем.
Рекомендации Google С++ довольно хороши ИМХО - с некоторыми незначительными поправками. Проверьте руководство здесь:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Почему необходимо согласовать? Пока код компилируется, и вы можете получить работу, не беспокойтесь об этом.
Я склонен быть перфекционистом, когда дело доходит до стиля кода, и это меня всегда беспокоило. Хотелось бы иметь универсальный стандарт, но его нет. В своей профессиональной карьере я обнаружил, что до тех пор, пока программисты по отдельному проекту будут согласованы, это лучшее, на что вы можете надеяться.
В конечном счете, я думаю, это сводится к пониманию, из какой библиотеки приходит метод, объект или функция. Если вы это знаете, тогда становится достаточно легко запомнить, какое соглашение используется этой библиотекой, предполагая, что проект не содержит много библиотек. Я пробовал адаптировать свой собственный код в соответствии с используемыми мной библиотеками, но он всегда является движущейся целью и просто разочаровывает в конце.
Fav quote::
Лучшее в стандартах - это то, что есть так много на выбор!
Мое предположение заключалось бы в том, чтобы чаще всего использовать правило библиотеки, которое чаще всего встречается в вашем корпоративном коде (вероятно, библиотека С++, которая, как я полагаю, также способствует повышению производительности), и сделайте это стандартом. В противном случае вы также можете не иметь его вообще.
В проектах, над которыми я работаю, я следую правилам кода для моего проекта. Когда я вызываю что-то другое, я использую API этой библиотеки.
Я также добавил бы, что упаковка библиотеки - плохая идея (их много в базе кода, над которой я работаю), потому что это обычно делается разработчиком, который решает свою проблему и, как правило, это неприемлемым для использования всеми другими разработчиками. С другой стороны, высококачественная упаковка дорогая.
Хорошо, поскольку мы не можем изменить способ реализации стандартных библиотек, я думаю, нам придется жить с ним. Что касается примирения - при написании некоторых компонентов Win32 API некоторое время назад я попытался называть свои собственные методы в PascalCasing, как это делалось в API, но это просто не чувствовалось. Поэтому я вернулся к названию своих методов в camelCase. Я согласен с этим, но другой вариант - адаптировать ваш стиль к каждой новой структуре или библиотеке, которую вы используете, а затем возникает проблема, связанная с наличием нескольких библиотек с использованием разных соглашений в одном проекте. Поэтому мой совет - придерживаться того, что кажется правильным для ваших собственных методов и занятий. Или - когда в корпоративной среде придерживайтесь лучших практик и рекомендаций вашей компании.
Кажется, я давно вспоминаю прочтение того, что они решили сделать стандартную библиотеку отличной от рекомендуемого соглашения о кодировании с целью избежать коллизий имен. Однако я не могу найти ссылку, которая упоминает об этом сейчас. Я помню, что читал, что вы не должны использовать ведущие строчные буквы в именах типов, потому что они зарезервированы для стандартных библиотек. Я предполагаю, что что-то подобное происходит с использованием символов подчеркивания. Я действительно не вижу нескольких соглашений об именах в качестве проблемы, поскольку он четко отделяет стандартный код от кода в вашем проекте. Я всегда кодирую вещи в своих проектах, используя случай с капюшоном с капюшоном для типов и нижний верблюд для методов/членов. В моем текущем рабочем месте используется случай с верблюжьим капиталом для методов в дополнение к типам, что сильно меня раздражает. Но они также любят венгерские бородавки, которые даже MS отменили: P
Честно говоря, я просто использовал бы библиотеку как есть и придерживаюсь своего стиля кодирования. Вы можете обернуть его, но это похоже на перебор.
Вы должны принять разницу.
Когда люди видят использование remove_copy_if, они сразу узнают, что это алгоритм. Это на самом деле положительная особенность, поскольку алгоритмы приходят с определенными гарантиями (или отсутствием).
Мы также используем соглашение об именах для собственных собственных алгоритмов.