Является ли переименование переменных после их типа плохой практикой?

Я программирую С++, используя стиль наименования подчеркивания (в отличие от случая с верблюдом), который также используется STL и boost. Однако, поскольку оба типа и переменные/функции называются всеми нижестоящими, объявление переменной-члена в следующем случае приведет к ошибкам компилятора (или, по крайней мере, к проблемам):

position position;

Переменная-член с положением, которая имеет позицию типа. Я не знаю, как еще назвать это: обычно это позиция, но это также позиция объекта. В случае с верблюдом это было бы хорошо с компилятором:

position position;

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

В C довольно часто используют для этого криптографические однобуквенные переменные:

int i;

Но я нахожу это немного, ну, загадочно:

position p;

Есть ли какие-либо эмпирические правила для имен переменных, которые я могу использовать, чтобы избежать этого?

В моем коде есть больше примеров, если вам нужно что-то для работы:

mouse_over(entity entity) // Returns true if the mouse is over the entity

manager &manager; // A reference to the framework manager

audio audio; // The audio subsystem

Edit:

Мне было любопытно узнать, есть ли у Бьярна Страустрапа что-то по этому поводу. Видимо, у него нет, но он предлагает соглашения о кодировании, которые будут работать вокруг моих проблем с компилятором:

Например, капитализируйте нестандартные пользовательские типы библиотеки и запустите нетипы с строчной буквой

Это будет соответствовать STL и boost, поэтому я могу использовать это. Однако большинство из вас согласны с тем, что этого наименования следует избегать, компилируется оно или нет. Так же Страуструп:

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

Ответ 1

Локальное значение редко является хорошим уникальным глобальным описанием типа:

cartesian_point_2d position;  // rectangular, not polar coordinates
mouse_over(ui_entity entity); // not a business layer entity
xyz_manager& manager;         // what a manager without something to manage?
audio_system audio;

Ответ 2

Предоставление переменной с тем же именем, что и ее тип, почти всегда является плохой идеей, потому что очень сложно сказать, какой код относится к типу и какой код относится к переменной. Например, рассмотрим следующий класс:

struct position
{
    void operator()() { }
};

// later on, somewhere:
position position;

Теперь, если мы видим строку кода, которая использует:

position()

мы не можем с готовностью сказать, поддерживает ли это объект position или вызывает position::operator()(). Нам нужно вернуться и посмотреть, есть ли в настоящее время объект с именем position.

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

На самом деле не имеет значения, как вы их различаете (ваши рекомендации по использованию капитализации или завершающего подчеркивания являются общими), только если ваше использование согласовано.

Ответ 3

Именование переменных после их типа, безусловно, является плохой практикой. Код должен быть как можно более независимым от типа. Это означает, что любые ссылки на фактические типы должны быть ограничены декларациями (опять же, насколько это возможно). Попытка внедрить информацию типа в имя переменной нарушит этот принцип. Не делайте этого.

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

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

Ответ 4

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

Ответ 5

Лично я использую имена моих классов.

Я не согласен с тем, "неразумно выбирать имена, которые отличаются только капитализацией", в этом конкретном случае. Неразумно выбирать имена, которые сбивчиво похожи. PoSItIoN и PoSItIoN схожу схожим образом. PoSItIoN и PoSItIoN - нет. Просто убедитесь, что при поиске кода вы знаете и можете контролировать, выполняете ли вы регистр с учетом регистра или нечувствительны.

В тех случаях, когда у меня есть функция, которая использует только одну переменную определенного типа, тогда я могу назвать ее после типа, поскольку на английском языке, если что-то было, "единственная позиция, о которой мы говорим", d относятся к нему как "позиция". Следовательно, имя переменной может быть PoSItIoN.

В противном случае, в ваших примерах я могу пойти с:

position pos;  // pretty sure people will realise I don't mean "positron".

mouse_over(entity target) // Returns true if the mouse is over the entity

manager &fmanager; // A reference to the framework manager

devices::audio audio; // The audio subsystem
audio self; // "this" audio subsystem
audio audio_out; // The audio subsystem I'm configured to use for output

Последний пример должен указывать на то, что эти проблемы могут быть решены пространствами имен - вне пространства имен, в котором определено audio, вы можете смело ссылаться на него как audio. Внутри этого пространства имен функции, работающие в аудиоподсистеме, часто либо являются частями интерфейса класса audio, которые просто становятся свободными функциями (в этом случае используют соглашения типа self, other, lhs, rhs), или же какое-то многоуровневое устройство или система, которые имеют аудиоподсистему как зависимость (в этом случае, зависимость для какой цели?).

entity и manager являются страшными именами для классов, между прочим, поскольку ни один из них не говорит вам ничего о том, что представляет класс. Каждая дискретная вещь является "сущностью", и, хотя не все управляет чем-то другим, "управлять" безнадежно расплывчато.

Ответ 6

Вот почему я взял старую MFC-практику префикса переменных-членов с помощью m_, как в "m_position". Многие люди Java будут делать "thePosition" по той же причине, хотя если бы вы указали на сходство в то время, когда они превратили бы смешные цвета и набросились на вас.

Ответ 7

У меня есть одна и та же "проблема" на регулярной основе. Я думаю, что это проблема абстракции: в случае Позиции я бы предложил немного отвлечься и ввести тип Точка или что-то в этом роде. Или укажите, какая позиция:

position mouse_pointer_pos;

Ответ 8

Вы можете просто следовать существующим правилам, например. Руководство по стилю Google С++

Хорошо знать, что именование является важной проблемой, но в моем опыте слишком много думать об этом так же вредно, как не осознавать этого.

Я экспериментировал с венгром и ему не нравилось, большинство хороших программистов я знаете, не используйте его.

Главное, что я сделал бы, это сделать код менее читаемым.

Ответ 9

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

Хотя я в действительности не согласен с этим. Я думаю, что у него есть доля правды, но только это.

Некоторые короткие имена переменных на С++ являются просто традиционными, и люди знают, что они означают, потому что они некоторое время программировали на C/С++. Использование i для индексной переменной - пример.

Я думаю, имена переменных должны быть названы по их назначению. Какова позиция позиции? Что управляющий управляет? Почему этот конкретный экземпляр аудиоподсистемы должен существовать?

Обозначение _ используется для различения имен переменных-членов. Это может быть очень полезно, когда кто-то начинает упоминать x из ниоткуда, чтобы видеть x_ и знать, что он исходит из класса и не объявлен в охватывающей области или глобальной области.