суббота, 5 сентября 2026 г.

[prog.c++] Всегда удивляюсь, когда вижу имена членов класса без суффиксов/префиксов

Данный пост навеян фрагментом кода из свежей статьи на хабре "Анатомия граблей", а именно вот этим фрагментом кода:

class Foo {
    int value;
public:
    Foo(int value) { // параметр затеняет поле class
        value = value; // ничего не делает, присваивает параметр самому себе
    }
};

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

У меня бы было написано так:

class Foo {
    int m_value;
public:
    Foo(int value) { // параметр ничего не затеняет
        m_value = value;
    }
};

И подобная опечатка сразу бы оказалась видна.

Но если уж префиксы или суффиксы для членов класса оскорбляют ваше чувство прекрасного, то возьмите за правило обращаться к ним через this->:

class Foo {
    int value;
public:
    Foo(int value) { // параметр затеняет поле class
        this->value = value; // ничего не затеняет
    }
};

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

PS. Самая странная система именования членов классов, которую доводилась видеть, была такой:

class Demo {
public:
  int a; // Открытый член класса без префикса или суффикса.

protected:
  int _b; // А вот защищенные и закрытые члены с префиксом.

private:
  int _c;
};

PPS. Касательно самой статьи "Анатомия граблей": она позиционируется как сборник C++ных граблей из области игростроя. Но практически все из описанного мне доводилось видеть в разнообразных проектах, которые к игрострою не имели никакого отношения. И какие-то из них (вроде выхода за границы статических массивов) не имеют дешевых решений, увы. По поводу же той части статьи, которая касается контроля за ресурсами и ручной работы с malloc/free, то слишком мало конкретики (плюс есть у меня подозрение, что в игрострое собирается публика, которой очень и очень фиолетово качество кода, но не факт, что подозрение верное).

Комментариев нет: