Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[34.205.246.61] |
|
Сообщ.
#1
,
|
|
|
Здравствуйте!
Перепробовал несколько стилей, но сталкиваюсь с какими-то неувязками. Мне просто интересно, как вы называете приватные нестатические поля в своих классах? Выскажу своё имхо о разных стилях, которые я пробовал или думал над ними. 1. называть по смыслу и не парится, имя существительное, которое обозначает то, что хранится в поле: . иногда не понятно, где здесь поле, а где нет, остаётся писать через this; . имена полей накладываются с именами параметров, особенно конструкторов; class someclass { public: someclass( const char* file_name, const int line_number ): file_name( file_name ), line_number( line_number ) { } private: char* file_name; int line_number; }; 2. перед названием поля, писать подчёркивание "_": . это не рекомендуется, поскольку имена с подчёркиванием зарезервированы для системных библиотек; class someclass { public: someclass( const char* file_name, const int line_number ): _file_name( file_name ), _line_number( line_number ) { } private: char* _file_name; int _line_number; }; 3. после названия поля, писать подчёркивание "_": . мне это не нравится. Помоему такое неудобно читать. Вообщем субъективная неприязнь; 4. после названия поля, указывать его тип: . прикольно, но годно не всегда; class someclass { private: button yes_button; button no_button; button cancel_button; }; 5. начинать название приватного нестатического поля с буквы "m" . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало; А какие есть ещё стили наименование приватных полей? p.s. Кодить лень, вот сижу и перфекционизмом страдаю. |
Сообщ.
#2
,
|
|
|
Цитата Eric-S @ 1. называть по смыслу и не парится, имя существительное, которое обозначает то, что хранится в поле: . иногда не понятно, где здесь поле, а где нет, остаётся писать через this; . имена полей накладываются с именами параметров, особенно конструкторов; Этот вариант ещё и к варнингам на pedantic-уровне приводит. Компилятор жалуется, что параметры конструктора скрывают поля класса. Цитата Eric-S @ 5. начинать название приватного нестатического поля с буквы "m" . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало; Уже лет надцать пользуюсь именно этим вариантом. Ничего, нормально. Вопрос привычки. |
Сообщ.
#3
,
|
|
|
Цитата Eric-S @ 5. начинать название приватного нестатического поля с буквы "m" . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало; я за 'm' а что mBlablabla, mBlablablaType, mBlablablaValue вполне читаемо. |
Сообщ.
#4
,
|
|
|
Цитата Flex Ferrum @ Уже лет надцать пользуюсь именно этим вариантом. Ничего, нормально. Вопрос привычки. Впринципе, могу согласится. Но хотелось бы понять, почему именно буква "m". Что оно обозначает? И ещё, это ведь не единичное соглашение, оно же из какой-то взаимосвязанной системы. Подскажите, какие в той системе есть ещё соглашения? Вроде бы: приватные статические поля с буквы "s". название приватных константных полей с буквы "c". название интерфейсов с буквы "i". название перечислений с буквы "e". название объединений с буквы "u". название псевдонимов типов с буквы "t". |
Сообщ.
#5
,
|
|
|
Цитата Eric-S @ Но хотелось бы понять, почему именно буква "m". Что оно обозначает? _m_ember. Добавлено Цитата Eric-S @ И ещё, это ведь не единичное соглашение, оно же из какой-то взаимосвязанной системы. Вообще, это из "венгерской нотации". Этакий огрызок, дошедший до наших дней. |
Сообщ.
#6
,
|
|
|
Цитата Flex Ferrum @ _m_ember. Нелогично. Ведь всё в классе, это тоже member'ы. Тогда надо использовать префикс "f" (field). Ах да, теперь понятно, почему в mfc, классы начинаются с буквы "c". Ух как меня это бесит. Добавлено Цитата Flex Ferrum @ Вообще, это из "венгерской нотации". Этакий огрызок, дошедший до наших дней. Ясно. Спасибо. Но ведь венгерская нотация это же microsoft, то есть плохо. Да и Торвальдс сказал, что плохо. Интересно, а как Линус помечает мемберы? |
Сообщ.
#7
,
|
|
|
Цитата Eric-S @ Интересно, а как Линус помечает мемберы? Что ты! Что ты! В линуксе нет C++ Цитата Eric-S @ Нелогично. Ведь всё в классе, это тоже member'ы. Ну, когда речь идёт о data membmer'ах - вполне логично. Функции просто иначе именуются (имя идёт от глагола, а не от существительного). Да и попутать data member с member function можно только в весьма специфичных контекстах. |
Сообщ.
#8
,
|
|
|
Цитата Flex Ferrum @ Да и попутать data member с member function можно только в весьма специфичных контекстах. У меня есть одно поле, там лежит функтор, который вызывается в методе. Названо поле, что премечательно, глаголом. |
Сообщ.
#9
,
|
|
|
Цитата Eric-S @ Названо поле, что премечательно, глаголом. Ну, это да. Но вот назвать метод существительным - уже не так "просто" |
Сообщ.
#10
,
|
|
|
Цитата Eric-S @ Ах да, теперь понятно, почему в mfc, классы начинаются с буквы "c". Ух как меня это бесит. почему бесит то? я наоборот доволен, что могу свои классы отличить от MFC |
Сообщ.
#11
,
|
|
|
По-скоку в С++ я пришел значительно позже плотного использования Перла - пришлось малеха "адаптироваться". Сейчас использую UpperCamelCase везде, кроме параметров функций и методов. Там я добавляю латинскую "i" в начале. А вот кодирование типов в идентификаторы не вношу, не вижу для себя профита (о5же наследие Перла - когда контроля типов нет), а вот обширными комментами при нетривиальном объявлении не брезгую. Получается, на мой взгдяд, не "вырвиглазно"
Получается что-то типа: #include <iostream> //TODO: обширные комменты))) class SomeClass { public: SomeClass(std::string iStr):Str(iStr){} std::string& Get() { return Str; } private: std::string Str = ""; }; // --------------------------------------------------------------------------------------- std::ostream& operator<<(std::ostream &iStream, SomeClass &iClass) { iStream << iClass.Get(); return iStream; } // --------------------------------------------------------------------------------------- int main() { SomeClass S = {"Some String"}; std::cout << S << std::endl; return 0; } Ну тут еще и "своя" табуляция в 2 пробела, и несишный способ расстановки фигурных скобок. |
Сообщ.
#12
,
|
|
|
Мне кажется более правильно использовать змеиный регистр так код выглядит более единообразным, со стандартной библиотекой. Которая использует именно змеиный регистр. |
Сообщ.
#13
,
|
|
|
Цитата Eric-S @ Мне кажется более правильно использовать змеиный регистр так код выглядит более единообразным, со стандартной библиотекой. Которая использует именно змеиный регистр. А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается. |
Сообщ.
#14
,
|
|
|
Цитата JoeUser @ А вот кодирование типов в идентификаторы не вношу, не вижу для себя профита (о5же наследие Перла - когда контроля типов нет) Ну, это-то понятно. Тоже особого смысла не вижу. А тему поднял, чтоб решить и выбрать стиль кодирования для название полей. Именно приватных полей класса. Утром сидел и ломал голову, как назвать поля нового класса, да так, чтоб оно не раздражало и не конфликтовало. Добавлено Цитата JoeUser @ кроме параметров функций и методов. Там я добавляю латинскую "i" в начале. А зачем? Какая в этом логика? Но впрочем, так точно не будет конфликтов названий параметров с названием полей. Добавлено Цитата JoeUser @ Ну тут еще и "своя" табуляция в 2 пробела, и несишный способ расстановки фигурных скобок. C++ тем и хорош, что позволяет выбрать наиболее симпатичный стиль кодирования. Я например от python, rust и go именно из-за стиля шарахаюсь. Добавлено Цитата Flex Ferrum @ А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается. Наверное дело вкуса и привычки. Мне же лень запоминать, кто в каком регистре был записан. Вообще, думаю, было бы прикольно, если бы убрали регистрозависимость для идентификаторов. И ещё бы сделали утилитку, которая бы конвертировала идентификаторы в предпочетаемый стиль именования. Добавлено Цитата Flex Ferrum @ вот назвать метод существительным - уже не так "просто" Согласен. Тут вообще отдельная тема. Ведь инкапсуляцияя намекает, что надо делать методы для полученияили изменения состояния объекта. Тоже ведь интересный вопрос, как назвать метод, который получает некую сущность, например хэндл окна. Я когда-то писал так: HWND handle() const { return window_handle; } Но тут возникает вопрос, как назвать методы для задания или сброса этого хэндла? Стал называть "get_handle", но тоже не то. Вообщем сейчас у меня: handle_type query_handle() const; void set_handle( handle_type value ); void unset_handle(); Тут у меня ещё идёт ломка. Но идея в том, что: query - возвращает значение. set - устанавливает значение. unset - сбрасывает значение. А вот методы: get - получают значение по ссылке, а возвращают флаг успеха. put - помещают значения и возвращают флаг успеха. Оно, лексически, кажеся более корректным, хотя традиционно get и set. Добавлено Цитата Cfon @ почему бесит то? я наоборот доволен, что могу свои классы отличить от MFC А потому, что при алфавитной сортировке они все в одной куче. |
Сообщ.
#15
,
|
|
|
Цитата Eric-S @ Мне кажется более правильно Тут не может быть более правильно. Это может быть кому-то удобно. Но кому-то и нет. Вспоминается совковая школа, когда левшей мучали - заставляли писать правой рукой. Потому, что им казалось, что писать левой рукой менее правильно Цитата Eric-S @ А зачем? Какая в этом логика? Но впрочем, так точно не будет конфликтов названий параметров с названием полей. Логика в том, что ты заметил. Да и параметр я проговариваю а-ля "ай что-за фигня в параметрах?") Цитата Eric-S @ Стал называть "get_handle", но тоже не то. Кстати ... тоже интересный вопрос! Но не про хэндл, а про составной идентификатор. В большинстве случаев составляем из "действия"+"некой сущности". Для себя принял для единообразия порядок "действие, потом сущность", типа GetLength, SetValue. Но в именовании полей класса, особенно для UI - наоборот. Типа BtnOk/BtnCancel, ChkSize, RbnValue1 ... Первые три буквы некое сокращение типа контролов. Хотя можно и полностью, но экономлю электричество на нашей планете. Добавлено Цитата Eric-S @ set - устанавливает значение. unset - сбрасывает значение. Можно оставить просто set. Если вызывается без параметра - это явно сброс, если с параметром - установка нового значения. Добавлено Цитата Flex Ferrum @ А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается. Кстати да, аналогично. |
Сообщ.
#16
,
|
|
|
Скрытый текст Цитата JoeUser @ Вспоминается совковая школа, когда левшей мучали - заставляли писать правой рукой. Ой! Не надо мне про это! Ужас-ужас-ужас! Я левша... К счастью на меня так сильно не давили. Но с письмом были дополнительные проблемы. Заставляли писать перьевой ручкой и чёрными чернилами. Типа так подчерк правильнее. А если писать левой рукой, то свеженаписанное смазывается этой же рукой. И манжеты рукавов, обязательно белой рубашки, вечно в чернильных пятнах. Я с тех пор возненавидел уроки чистописания и русского языка! А подчерк отвратительный, хуже чем кура лапой, никто прочитать не может. Цитата JoeUser @ Логика в том, что ты заметил. Да и параметр я проговариваю а-ля "ай что-за фигня в параметрах?") Понял. Но, кмк, твой вариант хуже. Ибо название параметра торчит какбы наружу. А название приватного поля скрыто внутри класса. |
Сообщ.
#17
,
|
|
|
Скрытый текст Значит ты понял смысл "более правильно" на своей шкуре Добавлено Цитата Eric-S @ Понял. Но, кмк, ваш вариант хуже. Ибо название параметра торчит какбы наружу. А название приватного поля скрыто внутри класса. У меня есть магическое заклинание в классе - "private" Добавлено Кстати ... предлагаю на "ты". А то как-то не комильфо на "вы", особенно после одного объяснения одессита) |
Сообщ.
#18
,
|
|
|
Цитата JoeUser @ Кстати ... тоже интересный вопрос! Но не про хэндл, а про составной идентификатор. В большинстве случаев составляем из "действия"+"некой сущности". Для себя принял для единообразия порядок "действие, потом сущность", типа GetLength, SetValue. Но в именовании полей класса, особенно для UI - наоборот. Типа BtnOk/BtnCancel, ChkSize, RbnValue1 ... Первые три буквы некое сокращение типа контролов. Хотя можно и полностью, но экономлю электричество на нашей планете. Про экономию понятно. Но, разгадывать шарады, иногда напрягает. Иногда так сократят, что даже не понятно, что хотели сказать. А вообще, тоже взял за правило, называть метод глагол и за ним существительное. Но тут есть ещё несколько заморочек. Вот как например назвать метод, который проверяет флаг, возможность, наличие? is_empty() can_create() has_childs() Или вот ещё, про тот же хэндл окна. Если у меня сам класс window_base, main_form, text_box, то метод query_handle() понятно, что возвращает хэндл этого самого окна. Но ведь у окна, есть и ещё другие сущности. С текстом понятно get_text( ... ) А если запрашивать другой хэндл? query_parent() query_module() query_menu() Это же тоже хэндлы. Значит, было бы логично, по тому же принципу, вместо query_handle() назвать query_window(). Но в таком случае масло-масленное. Добавлено Цитата JoeUser @ Кстати ... предлагаю на "ты". А то как-то не комильфо на "вы", особенно после одного объяснения одессита) Хорошо. Принято. Главное не забыть. А то я уже начал привыкать к этой шизофрении. Сижу постоянно на другом форуме, где все выкают. Добавлено Цитата JoeUser @ Можно оставить просто set. Если вызывается без параметра - это явно сброс, если с параметром - установка нового значения. У меня есть отдельные классы, там те методы виртуальные. Ну то есть set_handle вызывает do_set_handle. А unset_handle вызывает do_unset_handle. Разные имена методов, разделяют смысл. Ну а в других классах сделал для единообразия. Добавлено Цитата JoeUser @ Цитата Flex Ferrum @ А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается. Кстати да, аналогично. Ха-эм... А я вот наоборот, стараюсь унифицировать. И сильно страдаю, когда обнаруживаются некие расхождения с идиалом. Например в стандартных контейнерах вместо is_empty() метод просто называется empty(). А в std::locale вместо clear() метод называется empty(). Помоему гораздо проще, когда сущности унифицированы и приведены к единому стандарту. |
Сообщ.
#19
,
|
|
|
Цитата Eric-S @ Но, разгадывать шарады, иногда напрягает. Ну тут скорее надо понимать "правила игры". Если работа в команде - то работа по договоренностям. Если своя заморочка - твое право. Заметь, по-любому, единожды положенный внятный коммент к, например, кнопке - покроет все дальнейшие "затраты" на чтение))) Примеры: QPushButton *BntOk; // Кнопка закрытия диалога с принятием данных или QPushButton *ButtonForSubmitDialogData; Просто представь, когда этому кнопарю меняют состояние 10-15 раз. Второй вариант я бы использовал только под угрозой высокого напряжения! |
Сообщ.
#20
,
|
|
|
Цитата Eric-S @ проверяет флаг, возможность, наличие? Не могу аргументировать, но is_empty - считаю естественным. Цитата Eric-S @ Значит, было бы логично, по тому же принципу, вместо query_handle() назвать query_window(). Но в таком случае масло-масленное. get_query_items(enum Что_Кверить) Я бы так поступил. |
Сообщ.
#21
,
|
|
|
Цитата JoeUser @ get_query_items(enum Что_Кверить) Я бы так поступил. А!!! Адская жесть! Ржу немогу! Добавлено Цитата JoeUser @ Просто представь, когда этому кнопарю меняют состояние 10-15 раз. Второй вариант я бы использовал только под угрозой высокого напряжения! Дас... Тоже фигня. Но тут проблема даже не в длине, а в запоминании. Есть в std классы basic_streambuf и у них жуткие методы, название которых невозможно запомнить. Сокращения, причём я не понимаю даже каких слов. Хотя комментарии и даже документация есть. А ещё, когда сущность длинная, и ей нужно чего-нибудь много настроить, то я делаю на неё ссылочку. auto& btn = this->quit_push_button; btn.id = control_id::quit_button; btn... btn... |