Именование C++: read_input () по сравнению с readInput ()

Я предпочитаю использовать ускоренный маршрут и использовать стандартную библиотеку. Это означает lower_case_names . Мне нравится, что мой код читается в соответствии с STL.

underscores are often more prevalent on unix or cross platform code.

windows code tends to be camel cased

generally public, protected, private is what i would expect - but maybe that is more from my C# time.

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

Что касается спецификаций доступа к структуре / классу, вы обычно видите сначала общедоступные члены, затем защищенные, а затем частные (в порядке увеличения доступа контроль). Это сделано в основном для удобства чтения. Когда другие люди используют ваш код, они будут взаимодействовать с этими общедоступными членами, поэтому размещение их в верхней части объявления упрощает их поиск. Упорядочивание участников таким образом сохраняет наиболее часто используемую информацию ближе к началу. Я не видел, чтобы friend использовали слишком часто, поэтому я не могу вспомнить какие-либо шаблоны его использования. typedef обычно появляется вверху, так что при просмотре остальной части класса читатель уже имеет представление о ваших пользовательских типах (также для удобства чтения, typedef s обычно сгруппированы вместе, а не перемежаться с объявлениями членов).

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

Вот несколько соглашений по кодированию, которые, возможно, могут дать вам некоторые идеи:

• Стиль кодирования ядра Linux
• Рекомендации по кодированию OpenTracker
• Руководство Google по стилю C ++
• Соглашения о кодировании C ++ от id Software
  (декабрь 2017 г .: PDF-файл с соглашениями о кодировании больше не доступен.)
• Стандарт кодирования Университета Райса

Я использую символы подчеркивания для локальных переменных; ALL_UPPERCASE для макросов и констант; camelCase ни для чего и CamelCase для всего остального.

Я всегда использую структуры и никогда не классы, и поэтому начинаю с public: (не указывая его), а затем помещаю private: в конец.

Это все очень субъективно и так. нет правильного или неправильного ответа.

Какое соглашение об именах больше предпочтительнее в C ++? Undercore метод или метод camelCase? я имею кодировался на Java какое-то время, и я используется для именования CamelCase условности. Какой из них больше распространены?

Я бы сказал: «Просто придерживайтесь того, что вы знаете об этом, если вы начинаете писать свои собственные библиотеки», они обе используются регулярно.

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

Это зависит от программиста / команды. Заказываю по категориям. Я использую категорию для «внутренних / частных методов», и эта категория обычно предпоследняя (последняя запрещенная реализация).

Друзья обычно помещаются в конец?

Я использую их редко; Я вставляю их над зависимостью (методом), в противном случае - после категории конструктор / деструктор.

А что насчет определений типов, они находятся в верхней части определения класса?

Вот где я их помещаю.

Если вы хотите вдаваться в подробности, существуют общедоступные соглашения о кодировании.

Обычно я уважаю традиции платформы / среды, в которой я программирую, за исключением мультиплатформенных проектов C / C ++, где я нейтрален. При программировании C ++ для платформы Win32 я обычно использую венгерскую нотацию для переменных (тип или семантические префиксы). При программировании переменных-членов MFC MFC и т. Д. Единственное, что мне не нравится, - это соглашение Unix / POSIX open_device_driver по сравнению с openDeviceDriver стилем camelcase.