Заметки про код-стайл в C++

[Explorus]

В каком стайлгайде Вы видели использование подчеркивания в начале имени? В конце имени подчеркиваине для того, чтобы показать, что это член класса (Google С++ Styleguide). Да, встречается код, где в начале имени подчеркивание добавляют из тех же соображений, но распространенной практикой это назвать сложно.

[shved4]

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

[shved4]

Такой стиль встречается в телеграм десктоп))

[slinkinone]

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

[Explorus]

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

[slinkinone]

Так и есть - это субъективный-объективизм)

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

[shved4]

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

[domix32]

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

Другая проблема - подсказки от редакторов. Когда у вас в коде всплывают var и var_, то член класса будет обычно отсортирован вторым по порядку и можно случайно выбрать не то что ожидалось и потом тратить время чтобы найти косяк в методе. _var в этом плане полезнее, т.к. сразу видно намерение.

Что-нибудь типа

Foo::Foo(int myvar)
  : myvar_(myvar) {} // поди не промахнись с выбором подсказки
Foo::do_something(int myvar) {
  int data = process();
  // много строчек кода
  // 
  //
  myvar = data; // как скоро заметишь что myvar_ не поменялся
                // без статанализа - только при запуске
}

Bar::Bar(int myvar)
  : _myvar(myvar) {} // при вводе подчерка покажет всех членов класса
Bar::do_something(int myvar) {
  int data = process();
  // много строчек кода
  // 
  //
  _myvar = data; // переменная механически отлична от локальных переменных

}

что глаз цепляется за подчеркивание в конце имени после его прочтения и сразу понимаешь

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

[domix32]

Раньше использовали m_ и g_ для непубличных членов, сейчас перешёл на просто одинарное подчеркивание в членах класса. Двойное не использую, чтобы не зацепить никакие built in.

[monah_tuk]

Аналогично пробую. Ещё иногда пытаюсь в snake_case, но не хватает визуального отличия в некоторых местах в отсутствии подсветки. Но для себя писал стайл гайд, основа camelCase и m_

[sergio_nsk]

Был не прав.

[john_crew]

Кто как хочет, кому как удобно, и как договорятся, на мой взгляд.

Глобальная функция / статичный метод класса - с заглавной буквы (GetInstance, Init).

Метод класса, локальная переменная - с прописной (getValue, setOption, process).

Константа или макрос - всё заглавными (MAX_SIZE, PI, APP_ID).

Раньше я использовал _ вначале имен переменных/членов класса, мне было удобно в редакторе просматривать что у меня есть, но как-то незаметно для себя переехал на постфиксный стиль))

[oficsu]

Завтра кто-то добавил акроним: _URL

Писать акроним капсом – это всё ещё плохая идея безотносительно подчёркивания, поскольку имя переменной капсом пересекается с общепринятым неймингом констант или макросов

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

[shved4]

Я такое не раз встречал в коде старших разработчиков (5+ лет в индустрии)...

[yaroslavp]

m_<имя>, люблю такое, никаких подводных, всем все понятно

[old2ev]

В основном как в команде определено, так и нужно код оформлять, но лично для себя я использую следующие правила:

• PascalCase - всё что является типом данных (class, struct, enum, и т.д.)

• camelCase - всё что может вызываться (функции, функторы в том числе лямблы) и первое слово всегда глагол: set…, get…, is…, load… и т.д.

• snake_case - данные (переменные, поля классов, аргументы функций), при чём не зависимо от константности.

Как по мне венгерская нотация, в любом её проявлении(в т.ч. _*, __*, m_*, g_* и т.д.) давно изжила себя - на дворе далеко не 72-й год, для этих же целей в любой уважающей себя IDE давно присутствует такая замечательная штука как статический анализатор, который в случае необходимости подробно покажет и расскажет что, где и как хранится, зачем для этого городить какие-то избыточные правила нейминга, заставляя всю команду разработки их соблюдать. Тем более не вижу смысла в C++ использовать префиксы библиотек, как это делает Qt (QObject, QCoreApplication, QSettings и т.д.), для этих целей вообще-то в языке пространства имён есть.