Может ли начальные переменные / члены с подчеркиванием озадачить компилятор?

Со средней школы меня учили определять переменные следующим образом:

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 #. Я не пользуюсь компилятором Microsoft C ++ или ужасно много знаю об окружающей среде, поэтому из своего опыта работы с C # я понял, что они используют этот стиль именования в C ++. Никогда не сделали никаких заявлений о том , что C # правило пришло первый.

КЧалу

Ответы:

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

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

Так что, по большей части, в большинстве случаев безопасно использовать эти префиксы, НО, если вы их не используете, у вас есть 100% гарантия, что ваши имена никогда не будут конфликтовать с именами реализации.

Вот почему, в сомнении, не используйте этот префикс.

Klaim
источник

Ваши комментарии относятся к префиксу двух подчеркиваний, но не к одному подчеркиванию

Kate Gregory

@KateGregory: имена с начальным подчеркиванием зарезервированы для использования реализацией для имен в глобальном пространстве имен. Начальное подчеркивание, за которым следует второе подчеркивание или заглавная буква, зарезервировано для любого использования (они могут использоваться для макросов реализацией). Таким образом, начальное подчеркивание, за которым следует буква в нижнем регистре, может быть приемлемым в локальных областях, но лучше избегать его, чтобы избежать путаницы и использования зарезервированного имени.

Барт ван Инген Шенау

@KateGregory: Как член, _limitэто не ошибка, а глобальная функция. Я думаю, что лучше иметь простую политику, которая гласит: «не используйте начальные подчеркивания без исключения», чем политика, которая позволяет им в одних контекстах, а не в других. Но мы можем согласиться с этим по-разному. И чтобы было ясно, у меня нет проблем с подчеркиванием в других местах, кроме самого начала.

Барт ван Инген Шенау

@BartvanIngenSchenau: просто для интереса: простая политика, такая как «используйте ведущие подчеркивания только для частных учеников», не должна приводить к техническим проблемам, как вы думаете, это правда?

Док Браун

@KateGregory Просто чтобы уточнить, я согласен, что правила более точные, чем то, что я говорю в своем ответе; но это отражает отсутствие точности моей памяти, когда я пытаюсь вспомнить, какие именно правила. Поскольку я стараюсь избегать необходимости знать исключения (а не функцию), я предпочитаю общие правила, которым легко следовать, в частности, для таких не очень важных правил. Самое интересное, что я чувствую себя более комфортно с семантикой движения, чем вспоминаю об этом. Может быть, это не весело сейчас, когда я думаю об этом ...

Klaim

Использование двух подчеркиваний определенно плохо - это зарезервировано для деталей реализации, специфичных для компилятора. Это не относится к использованию одного подчеркивания.

Некоторые люди ненавидят подчеркивание. Называете ли вы что-то m_indexили highest_priceили _a- они ненавидят это. 25 лет назад я работал с кем-то, кто рассказывал мне о конкретном принтере IBM (очень популярном), который умещается в большее количество строк на странице, пропуская нижний пиксель в каждой другой строке. Это было хорошо для заметок или для вывода большого количества чисел и тому подобного, но имело эффект для кода, делающего половину ваших подчеркиваний невидимыми. (Да, действительно!) Люди этого поколения обычно испытывают иррациональную ненависть к подчеркиванию, либо от взаимодействия с этим принтером, либо от работы с кем-то, кто вбивает в них то, что подчеркивание не должно использоваться.

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

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

Рассматриваемый принтер давно отсутствует. Если вам нравится использовать одно подчеркивание за раз, не стесняйтесь. Но поймите, подчеркивающие ненавистники все еще существуют.

Кейт Грегори
источник

«Если вы называете что-то m_index или самое высокое_цену или _a - они ненавидят это» Не без причины! Вы не упомянули о том, что в стандартах есть правила, относящиеся конкретно к использованию начальных подчеркиваний в идентификаторах. Зачем просить неприятностей, когда их так легко избежать? stackoverflow.com/a/228797

Макс Барраклоф

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

Кейт Грегори

«Это не относится к использованию одного подчеркивания» - это не вся история, см. Мою ссылку, в которой говорится, что ведение с двойным подчеркиванием - это довольно определенное нет-нет, но что «Зарезервировано в глобальном пространстве имен: идентификаторы начинаются с нижнее подчеркивание". Зачем играть с огнем?

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

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

Кейт Грегори

Вот где мы не согласны. Да, иногда законно начинать идентификатор с одного подчеркивания. Как я сказал выше, зачем играть с огнем? Я никогда не начинаю идентификатор с подчеркивания; Я рассматриваю это как запах кода (если можно сказать, что он «видит» запах :-P). Таким образом, я никогда не беспокоюсь о специфике правил, которые точно говорят мне, когда это законно.

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