Соглашение об именах для параметров ctors и сеттеров

Question

Для тех из вас, кто называет ваши переменные-члены без специальных обозначений, таких как m_foo или foo_, как вы называете параметры для своих ctors и сеттеров?

Некоторые варианты, которые я пробовал до сих пор ...

Obj(int foo) : foo(foo) { }
void set_foo(int foo) { this->foo = foo; }

Obj(int _foo) : foo(_foo) { }
void set_foo(int _foo) { foo = _foo; }

Obj(int a_foo) : foo(a_foo) { } // a for "argument"
void set_foo(int a_foo) { foo = a_foo; }

Obj(int init_foo) : foo(init_foo) { }
void set_foo(int new_foo) { foo = new_foo; }

Answer 1

Я использую foo_, это лучше, чем _foo, поскольку он не будет конфликтовать с именами функций и ключевыми словами, специфичными для реализации.

Answer 2

Я иду с

Obj(int foo) : mFoo(foo) { }
void setFoo(int foo) { mFoo = foo; }

в моих программах. Для конструкторов копирования и оператора =, я склонен называть это

Obj(Obj const& that):mFoo(that.mFoo) { }

Для операторов я собираюсь с

Obj operator+(Obj const& lhs, Obj const& rhs) { ... }

Потому что это l eft h и s ide и r ight h и s ide of it.

Answer 3

Я всегда так делаю:

Obj(int foo) : foo(foo) {}

Раньше я играл в игры с добавлением забавных символов, пока однажды меня не поразили:

Obj(Bar& b) : b_(b_) {}

Вы видите ошибку? (Да, b_ - это ссылочная переменная закрытого члена). Составлено без предупреждения. Мне стоило 3 дня отладки (тогда я был зеленым программистом).

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

Answer 4

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

Прочитайте это: Каковы правила использования подчеркивания в идентификаторе C ++?

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

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

int X::setWork(int work)
{
    this->work = work;  // OK. But more Java like.

    work = work;        // Compiler won't see that problem.
}

int X::setWork(int newWork)
{
    work = newWork;    // A bit harder to get wrong.
}

Answer 5

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

void setFoo(int f) { foo = f; }

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

Кроме того, я часто делаю это

int setFoo(const int f) { foo = f; }

чтобы я мог связать вещи воедино.

Answer 6

Я следую Руководству по стилю Google C ++

Все имена переменных строчные, с подчеркиванием между словами. Переменные-члены класса имеют завершающие подчеркивания. Например: my_exciting_local_variable, my_exciting_member_variable _.

Answer 7

Я делаю это так:

obj(int foo) : _foo(foo) { }
int foo() const { return _foo; }
void foo(int value) { _foo = value; }

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

Answer 8

Я называю настоящих членов конечными подчеркиваниями, поэтому я делаю это:

Foo(int bar) : bar_(bar) { }

Причина в том, что я могу использовать функции получения без чего-либо вроде getBar () (bar () лучше).

Answer 9

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

Answer 10

Раньше я следовал соглашению Microsoft с префиксом переменных-членов с m_, например m_foo. В моей нынешней компании это условное подчеркивание для переменных-членов: foo_.

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