Подтвердить что ты не робот

Переменные элемента С++

Рассмотрим следующий класс:

class A
{
  A();
  int number;
  void setNumber(int number);
};

Вы можете реализовать 'setNumber' тремя способами:

Метод 1. Используйте указатель 'this'.

void A::setNumber(int number)
{
  this->number = number;
}

Метод 2. Используйте оператор разрешения области.

void A::setNumber(int number)
{
  A::number = number;
}

Метод 3. Вместо этого обозначьте все переменные-члены с помощью "m" или "_" (это мой предпочтительный метод).

void A::setNumber(int number)
{
  mNumber = number;
}

Является ли это только личным предпочтением или есть преимущество в выборе конкретного метода?

4b9b3361

ОТВЕТЫ

Ответ 1

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

У этой ссылки есть несколько полезных, связанных, ответов: Зачем использовать префиксы для переменных-членов в классах С++

Ваш вариант 1:

void A::setNumber(int number)
{
  this->number = number;
}

Во-первых, многие программисты склонны находить это громоздким, постоянно набирать "this- > ". Во-вторых, и что более важно, если какая-либо из ваших переменных разделяет имя с параметром или локальной переменной, find-replace, предназначенная, чтобы сказать, изменить имя "число", может повлиять на переменные-члены, находящиеся в области поиска-замены, как хорошо.

Ваш вариант 2:

void A::setNumber(int number)
{
  A::number = number;
}

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

Ваш вариант 3:

void A::setNumber(int number) 
{
  mNumber = number;
}

Это лучший из трех представленных вариантов. Создавая (и удерживая!!) Синтаксис, который включает в себя четкий и значимый префикс, вы не только создаете уникальное имя, которое не будет использовать локальная (или глобальная) переменная, но вы сразу же очистите, где объявлена ​​эта переменная, независимо от контекста, в котором вы его находите. Я видел, как это делалось как "mVariable" и как этот "m_variable", и в основном это зависит от того, предпочитаете ли вы подчеркивания для конкатенации верхнего регистра. Кроме того, если ваш стиль имеет тенденцию добавлять такие вещи, как "p on для указателей" или "g on for globals", этот стиль будет хорошо зашифрован и ожидается читателями.

Ответ 2

Это вопрос стиля, таким образом, личного предпочтения или предпочтения команды, с которой вы работаете, или босса команды, с которой вы работаете.

Ответ 3

Вариант 4:

void A::setNumber(int n)
{
  number = n;
}

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

Ответ 5

Я бы сказал, что выбор между Методом 1 и Методом 3 является вопросом личного или организационного стиля.

Метод 2 является неполноценным, поскольку Class:: member обычно обозначает статическую переменную-член и, таким образом, вызывает путаницу, если используется для устранения неоднозначности между параметром и переменной-членом.

Ответ 6

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

Вариант 4:

void A::setNumber(int aNumber)
{
  theNumber = aNumber;
}

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