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

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

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

// later on, somewhere:
position position;

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

position()

мы не можем легко сказать, создает ли это

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

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

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

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

лично я пишу названия классов с большой буквы.

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

в случаях, когда у меня есть функция, которая использует только одну переменную определенного типа, тогда я мог бы назвать ее после типа, так как на английском языке, если бы что-то было "единственной позицией, о которой мы говорим", мы бы назвали ее "позицией". Следовательно, имя переменной может быть разумно 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's 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 ужасные имена для классов, кстати, поскольку ни один из них ничего не говорит вам о том, что представляет собой класс. Каждая дискретная вещь является "сущностью", и хотя не все управляет чем-то другим," управление " безнадежно расплывчато.

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

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

position mouse_pointer_pos;

вы можете просто следовать существующим рекомендациям, например руководство Google по стилю C++

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

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

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

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

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

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

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

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