Чи є загальна норма про капіталізацію в С ++? [зачинено]

Я багато працюю в Python та Java, і обидві ці мови мають досить поширені (хоча і не універсальні) умови про те, як слід використовувати великі літери в ідентифікаторах: як PascalCaseдля імен класів, так і ALL_CAPSдля "глобальних" констант, але для інших ідентифікаторів багато Java-кодів використовує mixedCaseтой час як багато Python використовує код underscore_delimiters. Я знаю, що жодна мова чи бібліотека не вимагає використання великих букв, але я виявив, що коли я дотримуюся стандартних умов для мови, якою я користуюся, мій код здається набагато читабельнішим.

Зараз я починаю проект на C ++, і я хотів би застосувати ту саму ідею. Чи існує якась найпоширеніша конвенція про капіталізацію, про яку я повинен знати?

Чи існує якась найпоширеніша конвенція про капіталізацію, про яку я повинен знати?

C ++ базується на C, який є досить старим, щоб до моменту винайдення C ++ було розроблено цілу купу конвенцій про іменування. Тоді C ++ додав декілька, і C не замислювався і з думкою про нові. Додайте до цього багато мов, похідних від С, які далі розробили конвенції C про іменування винахідника, до того, що вони знову запліднювали C та C ++ ... Іншими словами: C ++ не має жодної, але багато таких умов.

Тим НЕ менше, якщо ви шукаєте однієї іменування, ви можете також подивитися на іменуванні стандартної бібліотеки , тому що це єдиний один , що розробники всього C ++ повинні знати і використовувати для.

Однак усе, що ви використовуєте, найважливіше правило: Будьте послідовні!

Цікаво, що, коли я починав поєднуватися з PascalCase і camelCase, і брав участь у численних проектах з ще більш численними конвенціями про іменування, з роками я виявляю, що все більше і більше застрягаю з standard_library_convention. Не питайте мене, чому.

Давайте спочатку погодимось з тим, що ВСЕ ПІДГОТОВЛЕННЯ - це очі, і їх слід мінімізувати.

Тому в C і C ++ він використовується як умова для макросів, і лише макросів, оскільки макроси однаково некрасиві, не кажучи про злі.

На початку C не було const, тому константи доводилося виражати як макроси. Крім того, в ті часи програми були набагато коротшими, так що практичні, які є недобрими сьогодні, можна було б використовувати (наприклад, IIRC Брайан Керніган написав код з великою кількістю макросів, що не мають великих літер). А також у ті часи існували клавіатури, які не мали малих літер; Я використовував один такий, на комп'ютері норвезького Тандберга EC-10, приблизно 1980 або 1979 роки, я думаю, що це було.

Отже, Java зібрала конвенції великих літер для констант з раннього часу C. Тим часом, а можливо, навіть до цього (я не впевнений у хронології тут), C отримав константи. Однак, хоча, звичайно, деякі / багато програмістів С були застрягли в попередній конвенції за потребою констант як великих макросів, програмісти C ++ були більш чутливими.

Зараз велика проблема полягає в тому, коли люди навчають спочатку Java, або С (спочатку середніх віків), а потім приходять до С ++, беручи з собою цю неприємну велику угоду.

Так,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Добре, ви могли подумати, що я жартома згадував лише великі клавіатури. О ні. Тому що це лише найдавніше, найархаїчніше обмеження технологій, яке призвело до конвенцій іменування, або, принаймні, вплинуло на те, наскільки вони неправильні / правильні. Далі виникла проблема 7-бітної послідовної передачі, яка спричинила відповідні проблеми із використовуваними кодами символів (новомовними кодовими символами), що означало, що вам доведеться обмежитися літерами англійського алфавіту, від A до Z.

Насправді я рекомендую все одно це робити. Ось де ми є! Ми не дійшли далі.

На даний момент, станом на 2011 рік, стандартний C ++ підтримує загальний Unicode в іменах (і це робиться з 1998 року), тоді як реальні C ++ реалізації не мають. Зокрема, компілятор g ++ є викликом національного характеру. Це випливає з того темного століття технологічного обмеження.

Так,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Нарешті, з приводу підкреслення проти перекреслених великих літер,

• Зарезервуйте легко розпізнавану форму для імен типів.
• Зарезервуйте ВСЕ ПІДТРИМКА для макросів.
• Будьте послідовними.

Я думаю, що це насправді, за винятком правил типу "взагалі уникайте однолітерного імені, крім (цикл, параметр шаблону, бла-бла)", і "уникайте використання l, легко плутайте з 1" і "уникайте великих букв O, легко плутайте з 0 ". Також, звичайно, уникайте використання зарезервованих імен, наприклад, починаючи з підкреслення з наступним великим регістром, що містить два послідовних підкреслення, або починати з підкреслення і знаходитись у глобальному просторі імен.

Ура & hth

Зазвичай я прагну дотримуватися тієї конвенції, яку я бачу більшість у існуючих кодових базах для мови. У випадку C ++ я зазвичай бачу camelCase. У випадку з Ruby або PHP я зазвичай бачу stuff_like_this.

Фактично кажучи, найголовніше - ви вибираєте конвенцію про стиль, яка не є абсолютно божевільною (dOnT_dO_tHiS) і дотримуєтесь її. Зробіть так, щоб стиль не змінювався протягом коду для конкретного проекту. Якщо ви працюєте над існуючим проектом, вам захочеться піти зі стилем, який вже є.

Що ж, є угорська системи, яка є справді поширеною навіть зараз, але я краще перерізав би своє горло, ніж рекомендував. Програми угорської мови краще, оскільки її анотаційні позначення справді вказують на семантику, хоча я вважаю, що вона занадто захоплена абревіатурами, коли буде зроблено коротке слово. (Щоб використовувати приклад із цієї сторінки Вікіпедії, навіщо використовувати rwдля рядка, коли rowдовгий лише один символ? Це не так, як є глобальний дефіцит голосних.)

Однак реально, найважливіше - це дотримуватися конвенцій людей, з якими ти працюєш . Дійсно. Більшість конвенцій працюють досить добре, особливо якщо вони використовуються послідовно. Невідповідність є найгіршою (навіть більше, ніж Система Угорська, яку я ненавиджу). А якщо ви самостійно, використовуйте все, що завгодно.

З того, що я бачив, це залежить від проектів.

Вбудовані підкреслення, ймовірно, більш традиційні / частіше використовуються в C на Unix. Стандартна бібліотека слід за цим , а також, так що це повинно майже напевно буде розглядатися як за замовчуванням, який буде використовуватися , якщо не достатньо існуючого коду з допомогою іншої конвенції абсолютно змусити використовувати це інший конвенції.

Windows (для одного прикладу) використовує чохол верблюда для більшості своїх функцій, тому досить багато людей, які розробляють для Windows, роблять те ж саме. Це також досить часто зустрічається серед людей, які насправді звикли до інших мов, і намагаються ставитися до C ++ так, ніби це просто дивний варіант чогось іншого.

Я використовував як стандартну бібліотеку, так і boost як посилання на конвенції іменування. Однак з цим рішенням є проблема.

У стандартній бібліотеці використовується режим іменування, призначений для спроби зменшити зіткнення з вашим кодом. Частина рішення полягає у використанні всіх малих літер. Звідси використання підкреслення замість camelCase.

Я вважаю, що camelCase читається. PascalCase часто використовується для назв класів, оскільки він є еквівалентом власного іменника. Однак я порушу це правило для функціонерів, які є більш представницькими для дієслова.

Я намагаюся не використовувати макроси. Однак коли я це роблю, макроси робляться схожими на функції, коли вони можуть. Я також використовую значення const або enums замість констант маніфесту, додатково уникаючи всього верхнього регістру. Я, як правило, префіксую ці символи знаком "k", щоб вказати, що вони постійні.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

Це посилання описує конвенцію про іменування, яка дуже схожа на ту, яку я бачив, що успішно використовувався щонайменше у трьох компаніях, над якими працював у минулому.

На відміну від попередньої відповіді, я би уникав дотримуватися конвенції про іменування Стандартної бібліотеки C ++ у своєму власному коді, якби не з іншої причини, окрім уникнення зіткнень імен зі Стандартною бібліотекою.

Ця попередня відповідь на відповідні теми також може зацікавити: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier