Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.223.0.53] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#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 @ А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается. Кстати да, аналогично. |