Чи можна запустити змінні / члени підкреслення загадкою компілятора?

Я ще з середньої школи вчив, що визначати такі змінні:

int _a;

або

int __a;

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

Наскільки мені відомо, це причина, чому деякі люди люблять переміщувати підкреслення в кінці назви, наприклад:

int a_;

Однак я бачу дуже багато коду, який використовує змінні, що починаються підкреслення. І цей код працює досить добре як із Visual Studio 2010, так і з g ++ 4.x.

Тож мені цікаво: чи це сьогодні не питання? Чи сучасні компілятори розумніші щодо іменних конвенцій?

c++ programming-practices naming-standards

— Еміліано
джерело

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

— KChaloux

Відповіді на це питання можуть бути корисними.

— Blrfl

@KChaloux, якщо ви думаєте, що команда компілятора Microsoft C ++ існувала вже понад 20 років, встановила правила щодо прийнятних імен ідентифікаторів на основі звичок деяких людей у команді C #, ви не знаєте, як працює Microsoft :-). Серйозно, минуло 21 рік, як вони випустили свій перший компілятор C ++, і ці правила повертаються далеко, або далі, в оригінальну базу коду компілятора C.

— Кейт Григорій

@Kate Я просто вказував, що я знаю, що вони використовували його в C #. Я не використовую компілятор C ++ від Microsoft або знаю дуже багато про навколишнє середовище, тому я вивів їх використання цього стилю іменування в C ++ зі свого досвіду роботи з C #. Ніколи не висловлював жодних претензій, що правило C # було першим.

— KChaloux

Відповіді:

Ви, мабуть, не розумієте причини підкреслення префікса - це погана практика. Якщо коротко, це тому, що стандарт C і C ++ резервує цей префікс для деталей реалізації, наприклад, для стандартної реалізації бібліотеки. (зауважте, що _ і __ не зарезервовані для одних і тих же речей, див. коментарі)

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

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

Ось чому, сумнівайтеся, не використовуйте цей префікс.

— Клаїм
джерело

ваші коментарі стосуються префіксу двох підкреслень, але не до жодного підкреслення

— Кейт Грегорі

@KateGregory: Імена з провідним підкресленням зарезервовані для використання реалізацією для імен у глобальному просторі імен. Початкове підкреслення, що супроводжується другим підкресленням, або великою літерою, зарезервовано для будь-якого використання (їх можна використовувати для макросів). Таким чином, провідне підкреслення, за яким слід вводити малі літери, може бути нормальним у локальних областях, але найкраще уникати, щоб уникнути перемикання та використання зарезервованого імені.

— Барт ван Інген Шенау

@KateGregory: Як учасник, _limitце не помилка, але є глобальною функцією. Я вважаю, що краще мати просту політику, яка говорить "не використовуйте провідні підкреслення без винятку", ніж політику, яка дозволяє їх в одних контекстах, а не в інших. Але ми можемо погодитись на те, щоб різнитися в цьому. І щоб бути зрозумілим, у мене немає проблем з підкресленнями в інших місцях, крім самого початку.

— Барт ван Іґен Шенау

@BartvanIngenSchenau: просто заради інтересу: проста політика на кшталт "використовувати провідні підкреслення лише та лише для членів приватного класу" не повинна призводити до технічних проблем, на вашу думку, це правда?

— Док Браун

@KateGregory Просто для уточнення я погоджуюся, що правила є більш точними, ніж те, про що я кажу у своїй відповіді; але це відображає недостатню точність моєї пам’яті, коли я намагаюся згадати, які саме правила. Оскільки я схильний уникати необхідності знати винятки (не особливості), я віддаю перевагу легким дотримуватися загальних правил, зокрема для таких не важливих правил. Найцікавіше те, що мені більше зручно семантично рухатись, ніж пам’ятати це. Можливо, це не весело зараз, коли я думаю про це ...

— Klaim

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

Деякі люди ненавиджу підкреслення. Якщо ви телефонуєте що - то m_indexабо highest_priceабо _a- вони ненавидять його. Я працював з кимось 25 років тому, який розповів мені про конкретний принтер IBM (дуже популярний), який відповідає більше рядків на сторінці, опускаючи нижній піксель у кожному другому рядку. Це було чудово для нагадувань, або для виведення великих фрагментів чисел і подібних, але впливало на код, роблячи половину ваших підкреслень невидимими. (Так, насправді!) Люди з цього покоління, як правило, ненавидять підкреслення, або від взаємодії з цим принтером, або від роботи з кимось, хто б'є в них, що підкреслення не використовуються.

Більшість людей вважають , використовуючи змішаний випадок (варіант у нас не було, скажімо, Fortran) більш чіткий підхід: mIndex, HighestPrice, aвстати дуже добре до раніше підкресленим прикладів. Я дам вам два правила:

ніколи не запускайте нічого (функцію, змінну, макро, typedef) з двома підкресленнями
виберіть послідовну конвенцію (наприклад, _limitдля параметрів функції, m_limitдля змінних членів, ніколи не використовуйте підкреслення, регістр верблюда, виписуйте великими літерами кожне слово, угорське, щось ) та дотримуйтесь його. Не торкайтеся іноді підкресленнями на початку, іноді в кінці, іноді не використовуючи їх, і п’ятьма різними умовами оболонок. Будьте послідовними.

Питання про принтер уже давно немає. Якщо ви хочете використовувати один підкреслення одночасно, сміливо. Але розумійте, ненависники підкреслення все ще існують.

— Кейт Григорій
джерело

"Незалежно від того, чи називаєте ви щось m_index або high_price або _a - вони зневажають це" Недарма! Ви не згадували про те, що в стандартах є правила, що стосуються конкретно використання провідних підкреслень в ідентифікаторах. Навіщо просити неприємностей, коли це так легко уникнути? stackoverflow.com/a/228797

— Макс Барраклу

не згадували? Прочитайте ще раз речення.

— Кейт Григорій

"Це не стосується використання однієї підкреслення" - це не вся історія, дивіться моє посилання, в якому йдеться про те, що просування з подвійними підкресленнями є досить певним "ні-ні", але що "Зарезервовано у глобальному просторі імен: ідентифікатори, що починаються з підкреслення ". Навіщо грати з вогнем?

— Макс Барраклу

ок, ви пропускаєте суть. У другому абзаці йдеться про існування людей, які, як правило, мають протизапис. Не провідні підкреслення. Усі підкреслення. Так, це правда, що крім правила про дві підкреслення, існує також правило про головне підкреслення, за яким йде велика літера, провідні підкреслення в глобальному масштабі тощо, але це вбік деякі люди все одно ненавидять підкреслення. І ці люди - це те, що я люблю неправильно називати. Не існує жодної причини, що базується на стандартах, для заперечень проти невідкладних підкреслень. Але люди так чи інакше роблять.

— Кейт Григорій

Тут ми не погоджуємось. Так, іноді законно починати ідентифікатор з одного підкреслення. Як я говорив вище, навіщо грати з вогнем? Я ніколи не запускаю ідентифікатор з підкресленням; Я розглядаю це як кодовий запах (якщо можна сказати, що він "переглядає" запах :-P). Таким чином, я ніколи не турбуюся про специфіку правил, які точно підказують мені, коли це законно робити.

— Макс Барраклу