Си диез / Говнокод #4827 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
if (m_Level != value)
                {
                    if (m_Level != null)
                    {
                        Logger.Unsubscribe(m_Level.Value, Logger_LogEvent);
                    }
                    m_Level = value;
                    if (m_Level != null)
                    {
                        Logger.Subscribe(m_Level.Value, Logger_LogEvent);
                    }
                }

Бывает и так. . .

Запостил: walash walash, (Updated )

Комментарии (33) RSS

  • пардон муа, это сеттер проперти что ли?

    зы: что за мудацкий код стайл "m_"?
    к мемберам (что бы не конфликтовали со стековыми переменными) надо обращаться через this.
    Ответить
    • Это кодинг стайл, распространённый и рекомендуемый в C++. В STL, в частности.
      Ответить
      • По-моему, это пропаганда от MS. Таких рекомендаций от C++ и STL в частности я не видел.
        Ответить
        • STL в gcc пестрит префиксами _M_ -- ещё хуже.

          Откуда пошла мода писать m_ -- не помню. Кажется это популяризировал один из столпов, вроде Майерса или Саттера лет десять назад. Во всяком случае распространилось. Может быть и от MS.

          Сам я предпочитаю _ (если только в проекте не принято иное). Но это дело вкуса и стандартных соглашений.
          Ответить
          • "_M_" есть, "m_" нет 🙂 А ещё "_S_" для static.
            В boost тоже как оказалось "m_" полно.
            Ответить
      • при современных IDE тем более в .NET он не имеет смысла.
        я и так знаю свойство это (поле вернее) или стековая переменная. Мне ReSharper подсветит
        Ответить
        • В C# и Java префикс действительно не нужен. А в C++ не обойтись -- пространство имён одно.
          Ответить
          • >А в C++ не обойтись -- пространство имён одно.
            О каком пространстве имен речь?
            Ответить
            • Логичный вопрос. 😉

              В С++ класс не может иметь поле данных something и метод something() (в Java и, насколько помню, C# -- может). Поэтому кому-то придётся уступить. Или getSomething()/get_something(), или префикс у приватного поля. Конфликт с именами параметров и локальных переменных -- это уже мелочь.
              Ответить
          • >>пространство имён одно.
            тоесть C++ внезапно неподдерживает неймспейсы?
            Ответить
            • Одно общее пространство имён для полей данных и методов.
              Ответить
      • Венгерка в .NET не нужна.
        Она только глаза мозолит. Давайте еще тип указывать:)

        int m_intAge; круто же
        Ответить
        • ну вот) судя по минусам -- как минимум три программиста тут пишут в FARе)))
          Ответить
          • По ходу дела у кого-то каникулы раньше времени настали. Вот крестик и давят где не лень.
            Ответить
          • в FARе? зачем в FARе? крутые спецы ваяют логику в экселе, которая потом будет читаться и исполняться )))) (на такой оригинальный подход я нарвался в одной крупной международной фирме)
            Ответить
              • знаем, знаем.
                потом крутой спец увольняется, а преемники уже знают, что если здесь нажать кнопку, то вон там из принтера полезет нужная бумажка.
                а потом легкое изменение формата входных данных и...
                Ответить
              • хз, там древний и огромный динозавр, который еле-еле шевелится. Я как увидел такого монстра, испугался. Задействована куча всяческих ява-технологий... Не знаю, какого хрена там экселевский формат...
                Ответить
    • Этому "мудацкому" стилю уже много лет. Понятно, что использовать венгерку по всем правилам с современными редакторами кода есть зло, однако именно мемберы до сих пор часто именуются особым образом. И два наиболее распространенных варианта - начало с "m_" и "_". Последний встречается очень часто. Например: http://www.rsdn.ru/article/mag/200401/codestyle.XML . И еще. Проработав в нескольких конторах, ни в одном коммерческом крупном проекте не встречал стиль "this.", что я только поддерживаю.
      Ответить
      • много лет -- это аргумент.
        а в старых сишных программах принято писать через подчеркивания и сокращать слова.

        так что писать так:
        lgr_lg_evnt

        а как пишут в RSDN это конечно очень важно)))

        На самом деле это конечно холивар. У жабы есть свой код-стайл: там принято обращаться напрямую, и только если свопадают названия -- через this.

        знаете почему?

        потому что в формуле: foo = (bar + 42) совершенно не важно -- является bar свойством инстанса, статическим свойством или стековой переменной.

        Но M$ в отличии от сана о код-стайле не позаботилась, и потому каждый пишет на C#, как он хочет: джависты через this, плюсплюсники через m_ (странно, что классы у них без префикса C например CString).


        так как в последнее время я пишу на джаве -- стиль this мне ближе.

        а m_ -- это совершенно ненужная информация. Любой IDE подсвечивает поля и переменные по разному. Потому m_ должен отправится туда же, куда отправился префикс int
        Ответить
        • Префиксы мемберов дают возможность быстро осуществлять навигацию по сгруппированным мемберам в редакторах с IntelliSense, решарпером и т.п. примочками. Так же как с this, конечно, только в 2-4 раза короче.
          Ответить
            • Возможно имелось в виду сортировка списка имен переменных.
              Ответить
              • Да, так яснее. Только имен не только переменных, понятное дело. Список всегда большой, в нем перечислены все имена в пределах области видимости. Т.к. часто приходится дорабатывать чужие классы, именно мемберы удобно видеть в одном месте. Локальные переменные и так все сразу налицо. Более того, с префиксом _, как правило, хватает двух нажатий на клавиши, чтобы написать имя мембера. Вроде удобство очевидно.
                Ответить
        • >(странно, что классы у них без префикса C например CString)
          Зато интерфейсы через I
          Ответить
  • Хороший, годный код. Лучше и не напишешь. Просто вникните, что он делает.
    Ответить
  • Код действительно не заслужил, чтобы его сюда запостили,
    а что кодестайл аля С++ - так это не автор виноват, а контора в которую он попал.
    Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8