На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
> стиль кодирования, название поля
    Здравствуйте!

    Перепробовал несколько стилей, но сталкиваюсь с какими-то неувязками. Мне просто интересно, как вы называете приватные нестатические поля в своих классах?

    Выскажу своё имхо о разных стилях, которые я пробовал или думал над ними.

    1. называть по смыслу и не парится, имя существительное, которое обозначает то, что хранится в поле:
    . иногда не понятно, где здесь поле, а где нет, остаётся писать через this;
    . имена полей накладываются с именами параметров, особенно конструкторов;

    ExpandedWrap disabled
      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. перед названием поля, писать подчёркивание "_":
    . это не рекомендуется, поскольку имена с подчёркиванием зарезервированы для системных библиотек;
    ExpandedWrap disabled
      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. после названия поля, указывать его тип:
    . прикольно, но годно не всегда;
    ExpandedWrap disabled
      class someclass
      {
      private:
      button yes_button;
      button no_button;
      button cancel_button;
      };


    5. начинать название приватного нестатического поля с буквы "m"
    . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало;

    А какие есть ещё стили наименование приватных полей?

    p.s.
    Кодить лень, вот сижу и перфекционизмом страдаю.
      Цитата Eric-S @
      1. называть по смыслу и не парится, имя существительное, которое обозначает то, что хранится в поле:
      . иногда не понятно, где здесь поле, а где нет, остаётся писать через this;
      . имена полей накладываются с именами параметров, особенно конструкторов;

      Этот вариант ещё и к варнингам на pedantic-уровне приводит. Компилятор жалуется, что параметры конструктора скрывают поля класса.


      Цитата Eric-S @
      5. начинать название приватного нестатического поля с буквы "m"
      . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало;

      Уже лет надцать пользуюсь именно этим вариантом. Ничего, нормально. Вопрос привычки. :)
        Цитата Eric-S @
        5. начинать название приватного нестатического поля с буквы "m"
        . э-э-э, как-то кривовато, смысл немного убегает, особенно при сортировке в документации, ну да ладно, полей мало;

        я за 'm' :D
        а что mBlablabla, mBlablablaType, mBlablablaValue вполне читаемо.
          Цитата Flex Ferrum @
          Уже лет надцать пользуюсь именно этим вариантом. Ничего, нормально. Вопрос привычки. :)

          Впринципе, могу согласится.
          Но хотелось бы понять, почему именно буква "m". Что оно обозначает?

          И ещё, это ведь не единичное соглашение, оно же из какой-то взаимосвязанной системы.
          Подскажите, какие в той системе есть ещё соглашения?

          Вроде бы:
          приватные статические поля с буквы "s".
          название приватных константных полей с буквы "c".
          название интерфейсов с буквы "i".
          название перечислений с буквы "e".
          название объединений с буквы "u".
          название псевдонимов типов с буквы "t".
            Цитата Eric-S @
            Но хотелось бы понять, почему именно буква "m". Что оно обозначает?

            _m_ember. :)

            Добавлено
            Цитата Eric-S @
            И ещё, это ведь не единичное соглашение, оно же из какой-то взаимосвязанной системы.

            Вообще, это из "венгерской нотации". Этакий огрызок, дошедший до наших дней.
              Цитата Flex Ferrum @
              _m_ember. :)

              Нелогично. Ведь всё в классе, это тоже member'ы.
              Тогда надо использовать префикс "f" (field).

              Ах да, теперь понятно, почему в mfc, классы начинаются с буквы "c". Ух как меня это бесит.

              Добавлено
              Цитата Flex Ferrum @
              Вообще, это из "венгерской нотации". Этакий огрызок, дошедший до наших дней.

              Ясно. Спасибо.
              Но ведь венгерская нотация это же microsoft, то есть плохо. Да и Торвальдс сказал, что плохо.
              Интересно, а как Линус помечает мемберы?
                Цитата Eric-S @
                Интересно, а как Линус помечает мемберы?

                Что ты! Что ты! В линуксе нет C++ :)


                Цитата Eric-S @
                Нелогично. Ведь всё в классе, это тоже member'ы.

                Ну, когда речь идёт о data membmer'ах - вполне логично. Функции просто иначе именуются (имя идёт от глагола, а не от существительного). Да и попутать data member с member function можно только в весьма специфичных контекстах.
                  Цитата Flex Ferrum @
                  Да и попутать data member с member function можно только в весьма специфичных контекстах.

                  У меня есть одно поле, там лежит функтор, который вызывается в методе.
                  Названо поле, что премечательно, глаголом.
                    Цитата Eric-S @
                    Названо поле, что премечательно, глаголом.

                    Ну, это да. Но вот назвать метод существительным - уже не так "просто" :D
                      Цитата Eric-S @
                      Ах да, теперь понятно, почему в mfc, классы начинаются с буквы "c". Ух как меня это бесит.

                      почему бесит то? я наоборот доволен, что могу свои классы отличить от MFC :D
                        По-скоку в С++ я пришел значительно позже плотного использования Перла - пришлось малеха "адаптироваться". Сейчас использую UpperCamelCase везде, кроме параметров функций и методов. Там я добавляю латинскую "i" в начале. А вот кодирование типов в идентификаторы не вношу, не вижу для себя профита (о5же наследие Перла - когда контроля типов нет), а вот обширными комментами при нетривиальном объявлении не брезгую. Получается, на мой взгдяд, не "вырвиглазно" :)

                        Получается что-то типа:

                        ExpandedWrap disabled
                          #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 пробела, и несишный способ расстановки фигурных скобок.
                          Цитата JoeUser @
                          Сейчас использую UpperCamelCase везде, кроме параметров функций и методов.

                          Мне кажется более правильно использовать змеиный регистр
                          так код выглядит более единообразным, со стандартной библиотекой. Которая использует именно змеиный регистр.
                            Цитата Eric-S @
                            Мне кажется более правильно использовать змеиный регистр
                            так код выглядит более единообразным, со стандартной библиотекой. Которая использует именно змеиный регистр.

                            А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается.
                              Цитата JoeUser @
                              А вот кодирование типов в идентификаторы не вношу, не вижу для себя профита (о5же наследие Перла - когда контроля типов нет)

                              Ну, это-то понятно. Тоже особого смысла не вижу.

                              А тему поднял, чтоб решить и выбрать стиль кодирования для название полей. Именно приватных полей класса.
                              Утром сидел и ломал голову, как назвать поля нового класса, да так, чтоб оно не раздражало и не конфликтовало.

                              Добавлено
                              Цитата JoeUser @
                              кроме параметров функций и методов. Там я добавляю латинскую "i" в начале.

                              А зачем? Какая в этом логика?

                              Но впрочем, так точно не будет конфликтов названий параметров с названием полей.

                              Добавлено
                              Цитата JoeUser @
                              Ну тут еще и "своя" табуляция в 2 пробела, и несишный способ расстановки фигурных скобок.

                              C++ тем и хорош, что позволяет выбрать наиболее симпатичный стиль кодирования.
                              Я например от python, rust и go именно из-за стиля шарахаюсь.

                              Добавлено
                              Цитата Flex Ferrum @
                              А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается.

                              Наверное дело вкуса и привычки. Мне же лень запоминать, кто в каком регистре был записан.

                              Вообще, думаю, было бы прикольно, если бы убрали регистрозависимость для идентификаторов. И ещё бы сделали утилитку, которая бы конвертировала идентификаторы в предпочетаемый стиль именования.

                              Добавлено
                              Цитата Flex Ferrum @
                              вот назвать метод существительным - уже не так "просто" :D

                              Согласен. Тут вообще отдельная тема.
                              Ведь инкапсуляцияя намекает, что надо делать методы для полученияили изменения состояния объекта.

                              Тоже ведь интересный вопрос, как назвать метод, который получает некую сущность, например хэндл окна.
                              Я когда-то писал так:
                              ExpandedWrap disabled
                                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 :D

                              А потому, что при алфавитной сортировке они все в одной куче.
                                Цитата Eric-S @
                                Мне кажется более правильно

                                Тут не может быть более правильно. Это может быть кому-то удобно. Но кому-то и нет. Вспоминается совковая школа, когда левшей мучали - заставляли писать правой рукой. Потому, что им казалось, что писать левой рукой менее правильно :lol:

                                Цитата Eric-S @
                                А зачем? Какая в этом логика?
                                Но впрочем, так точно не будет конфликтов названий параметров с названием полей.

                                Логика в том, что ты заметил. Да и параметр я проговариваю а-ля "ай что-за фигня в параметрах?")

                                Цитата Eric-S @
                                Стал называть "get_handle", но тоже не то.

                                Кстати ... тоже интересный вопрос! Но не про хэндл, а про составной идентификатор. В большинстве случаев составляем из "действия"+"некой сущности". Для себя принял для единообразия порядок "действие, потом сущность", типа GetLength, SetValue. Но в именовании полей класса, особенно для UI - наоборот. Типа BtnOk/BtnCancel, ChkSize, RbnValue1 ... Первые три буквы некое сокращение типа контролов. Хотя можно и полностью, но экономлю электричество на нашей планете.

                                Добавлено
                                Цитата Eric-S @
                                set - устанавливает значение.
                                unset - сбрасывает значение.

                                Можно оставить просто set. Если вызывается без параметра - это явно сброс, если с параметром - установка нового значения.

                                Добавлено
                                Цитата Flex Ferrum @
                                А мне вот как раз это "единообразие" не нравится. Привык визуально различать библиотечный код (или его расширения) и свой. А тут - всё сливается. Читаемость ухудшается.

                                Кстати да, аналогично.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0825 ]   [ 17 queries used ]   [ Generated: 28.03.24, 10:59 GMT ]