Чрезмерное использование this в C ++

Ваша версия немного чище, но пока вы ее, я бы:

1. Избегайте начального подчеркивания: _x можно, пока кто-нибудь не выберет _MyField, которое является зарезервированным именем. Начальное подчеркивание, за которым следует заглавная буква, не допускается в качестве имени переменной. См .: Каковы правила использования символа подчеркивания в идентификаторе C ++?
2. Сделайте атрибут частным или защищенным: изменение безопасно, если оно компилируется, и вы убедитесь, что ваш установщик будет использоваться.
3. История this-> используется, например, в шаблонном коде, чтобы сделать имя поля зависимым от вашего типа (может решить некоторые проблемы с поиском).

Небольшой пример разрешений имен, которые фиксируются с помощью явного this-> (проверено с g ++ 3.4.3):

#include <iostream>
#include <ostream>

class A
{
public:
  int g_;
  A() : g_(1) {}
  const char* f() { return __FUNCTION__; }
};

const char* f() { return __FUNCTION__; }
int g_ = -1;

template < typename Base >
struct Derived : public Base
{
  void print_conflicts()
  {
    std::cout << f() << std::endl; // Calls ::f()
    std::cout << this->f() << std::endl; // Calls A::f()
    std::cout << g_ << std::endl; // Prints global g_
    std::cout << this->g_ << std::endl; // Prints A::g_
  }
};

int main(int argc, char* argv[])
{
   Derived< A >().print_conflicts();
   return EXIT_SUCCESS;
}

Именование полей не имеет ничего общего с кодовым запахом. Как сказал Нил, видимость поля - единственный здесь кодовый запах.

Существуют различные статьи, касающиеся соглашений об именах в C ++:

• соглашение об именах для общедоступных и частных переменных?
• Соглашение об именах частных методов
• правила использования пространства имен и именования c ++

и Т. Д.

Такое использование слова "это" поддерживается стандартами кодирования Microsoft C #. Он дает хорошую ясность кода и призван стать стандартом по сравнению с использованием m_ или _ или чего-либо еще в переменных-членах.

Честно говоря, мне все равно не нравится подчеркивание в именах, я обычно ставил перед всеми участниками одну букву «m».

Многие люди используют это, потому что в их среде IDE будет появляться список идентификаторов текущего класса.

Я знаю, что участвую в BCB.

Я думаю, что приведенный вами пример конфликта имен является исключением. Однако в Delphi рекомендации по стилю используют префикс (обычно «a») для параметров, чтобы избежать именно этого.

Лично я считаю, что бороться с существующим соглашением о кодировании - это то, чего вам не следует делать. Как пишет Саттер / Александреску в своей книге «Соглашения о кодировании на C ++»: не переживайте по мелочам. Кто угодно может прочитать одно или другое, независимо от того, идет ли оно в начале "this->", "_" или что-то еще.

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

Если вы все-таки обнаружите, что для его изменения есть веская причина, не делайте этого вручную. В лучшем случае ваша IDE поддерживает такие «рефакторинги». В противном случае напишите сценарий его изменения. Последним вариантом должен быть поиск и замена. В любом случае у вас должна быть резервная копия (система контроля версий) и какое-то автоматизированное средство тестирования. Иначе вы не получите от этого удовольствия.

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

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

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

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

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

class MyClass
{
public:
  int m_x;
  void f(int p_x);
};


void MyClass::f(int p_x)
{
  m_x = p_x;
}

... я предпочитаю использовать префиксы области видимости. m_ для члена, p_ для параметра (некоторые вместо этого используют a_ для аргумента), g_ для глобального и иногда l_ для локального, если это помогает читаемости.

Если у вас есть две переменные, которые заслуживают одного и того же имени, это может очень помочь и позволяет избежать случайного изменения ее значения, чтобы избежать переопределения. Или, что еще хуже, ужасные «x2, x3, x4 и т. Д.» ...

В C ++ более нормально инициализировать элементы при построении с использованием инициализатора.

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

Сегодня большинство редакторов IDE раскрашивают ваши переменные, чтобы указать члены класса локальных переменных. Таким образом, IMO, ни префиксы, ни this-> не требуются для удобочитаемости.

Мне не нравится использовать «это», потому что это атавистично. Если вы программируете на старом-добром C (помните C?) И хотите имитировать некоторые характеристики ООП, вы создаете структуру с несколькими членами (они аналогичны свойствам вашего объекта) и создаете набор функций, которые все принимают указатель на эту структуру в качестве своего первого аргумента (они аналогичны методам этого объекта).

(Я думаю, что этот синтаксис typedef правильный, но это было давно ...)

typedef struct _myclass
{
   int _x;
} MyClass;

void f(MyClass this, int x)
{
   this->_x = x;
}

На самом деле я считаю, что старые компиляторы C ++ действительно скомпилируют ваш код в приведенную выше форму, а затем просто передадут его компилятору C. Другими словами - C ++ в какой-то степени был просто синтаксическим сахаром. Поэтому я не уверен, зачем кому-то программировать на C ++ и возвращаться к явному использованию «this» в коде - возможно, это «синтаксический Nutrisweet».

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

class tea
{
public:
    int cup;
    int spoon;
    tea(int cups, int spoons);
};

or

class tea
{
public:
    int cup;
    int spoon;
    tea(int drink, int sugar);
};

Думаю, вы уловили идею. Это в основном именование переменных разными, но «одинаковыми» в логическом смысле. Я надеюсь, что это помогает.