Соглашения об именовании переменных в C ++

Question

Я из мира .NET, и я новичок в написании C ++. Мне просто интересно, каковы предпочтительные соглашения об именах, когда речь идет о именовании локальных переменных и членов структуры.

Например, унаследованный код, который я унаследовал, имеет много таких:

struct MyStruct
{
   TCHAR           szMyChar[STRING_SIZE];
   bool            bMyBool;
   unsigned long   ulMyLong;
   void*           pMyPointer;
   MyObject**      ppMyObjects;
}

Исходя из фона C #, я был шокирован, увидев переменные с венгерской нотацией (я не мог перестать смеяться над префиксом pp в первый раз, когда увидел его).

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

struct MyStruct
{
   TCHAR           MyChar[STRING_SIZE];
   bool            MyBool;
   unsigned long   MyLong;
   void*           MyPointer;
   MyObject**      MyObjects;
}

Мой вопрос: является ли (прежний способ) по-прежнему предпочтительным способом именования переменных в C ++?

Ссылки:

http://geosoft.no/development/cppstyle.html

http://www.syntext.com/books/syntext-cpp-conventions.htm

http://ootips.org/hungarian-notation.html

Спасибо!

Answer 1

Такая венгерская нотация довольно бесполезна и, возможно, хуже, чем бесполезна, если вам нужно что-то изменить. ( * * * * * * * * * * * * * * * * *) *1004* - это другая история.

Я предлагаю вам использовать то, что делает ваша группа. Если вы единственный человек, работающий над программой, назовите его так, как вам будет удобно.

Answer 2

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

Answer 3

Нет. «Неправильная венгерская нотация» - особенно pp для двойной косвенности - имела смысл для ранних компиляторов Си, где можно было написать

int * i = 17;
int j = ***i;

даже без предупреждения от компилятора (и это может быть даже действительный код на правильном оборудовании ...).

«Настоящая венгерская нотация» (как связано с головой Geek) - это ИМО, все еще допустимый вариант, но не обязательно предпочтительный. Современное приложение C ++ обычно имеет десятки или сотни типов, для которых вы не найдете подходящих префиксов.

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

float fXmin, fXmax, fXpeak; // x values of range and where y=max
int   iXmin, iXMax, iXpeak; // respective indices in x axis vector

---

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

Мое рассуждение: цель стандартов кодирования - соответствовать принципу наименьшего удивления. Последовательное использование одного стиля важнее, чем стиль, который вы используете.

Answer 4

Что не нравится или насмехается над "ppMyObjects" в этом примере, кроме того, что он несколько уродлив? В любом случае, у меня нет сильных мнений, но он дает полезную информацию с первого взгляда, чего нет у «MyObjects».

Answer 5

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

Переменные-члены класса / структуры должны выделяться - я обычно ставлю перед ними префикс m_
Глобальные переменные должны выделяться - обычно префикс с g_
Переменные в общем случае должны начинаться со строчной буквы
Имена функций в общем случае должны начинаться с заглавной буквы
Макросы и, возможно, перечисления должны быть в верхнем регистре
Все имена должны описывать, что делает функция / переменная, и никогда не должны описывать ее тип или значение.

Answer 6

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

Тем не менее, я думаю, что вы можете привести в жертву ваш предпочтительный стиль и некоторую дополнительную поддержку для единства команды. Я не покупаю аргумент согласованности ради равномерной читабельности кода, особенно если вы снижаете читабельность для согласованности ... это просто не имеет смысла. Вместе с тем общение с людьми, с которыми вы работаете, может стоить немного больше путаницы с типами, которые смотрят на переменные.

Answer 7

Наша команда использует Соглашение о коде Google C ++ :

Это образец имени переменной:

string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.

string tableName;   // Bad - mixed case.

Answer 8

Я также предпочитаю CamelCase, в основном я видел людей, использующих CamelCase в C ++. Лично я не использую никаких префиксов для частных / защищенных членов и интерфейсов:

class MyClass : public IMyInterface {
public:
    unsigned int PublicMember;
    MyClass() : PublicMember(1), _PrivateMember(0), _ProtectedMember(2) {}
    unsigned int PrivateMember() {
        return _PrivateMember * 1234; // some senseless calculation here
    }
protected:
    unsigned int _ProtectedMember;
private:
    unsigned int _PrivateMember;
};
// ...
MyClass My;
My.PublicMember = 12345678;

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

struct IMyInterface {
    virtual void MyVirtualMethod() = 0;
};

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

struct IMyInterfaceAsAbstract abstract {
    virtual void MyVirtualMethod() = 0;
    virtual void MyImplementedMethod() {}
    unsigned int EvenAnPublicMember;
};

См. Стандартное руководство по кодированию High Integrity C ++ для получения дополнительной информации.

Answer 9

Все зависит от личных предпочтений. Я работал на 2 компании с похожими схемами, где члены-члены называются m_varName. Я никогда не видел, чтобы венгерская нотация использовалась на работе, и она мне действительно не нравилась, но опять же, к предпочтениям. Мое общее мнение состоит в том, что IDE должны позаботиться о том, чтобы сообщить вам, какой это тип, так что пока имя достаточно наглядно описывает, что оно делает (m_color, m_shouldBeRenamed), тогда это нормально. Еще одна вещь, которая мне нравится, это разница между переменными-членами, локальными переменными и именами констант, поэтому легко увидеть, что происходит в функции и откуда происходят переменные. Участник: m_varName Const: c_varName local: varName

Answer 10

Я думаю, что вы все равно обнаружите, что большинство магазинов, которые программируют на Visual C ++, придерживаются венгерской нотации или, по крайней мере, ее разбавленной версии. В нашем магазине половина нашего приложения - унаследованный C ++ с блестящим новым слоем C # сверху (с управляемым слоем C ++ в середине). Наш код C ++ продолжает использовать венгерскую нотацию, но наш код C # использует нотацию, как вы представили. Я думаю, что это некрасиво, но последовательно.

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