1. C# / Говнокод #19174

    +8

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    public static class StringExtensions
        {
            public static bool IsNulldOrEmpty(this string str)
            {
                return string.IsNullOrEmpty(str);
            }
        }

    why

    Запостил: antoanelenkov, 12 Декабря 2015

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

    • Секс.
      Ответить
    • Де-ле-ги-ро-ва-ние
      Ответить
    • У меня тоже самое, говорят: "легаси не трогай", но помечен obsolete'ом.
      Ответить
    • дабы можно было сделать null.IsNullOrEmpty() конечно же
      Ответить
    • Потому что на 5 символов короче код каждый раз получается!
      Ответить
    • >this string str
      Что это?
      Ответить
      • Синтаксис для экстеншн методов. Чтобы потом у любой хуйни можно было вызвать huinya.IsNulldOrEmpty() и huinya попал в str.
        Ответить
        • Что за вещь - экстеншн методов?
          Ответить
          • https://msdn.microsoft.com/en-us/library/bb383977.aspx
            Ответить
            • Накуа?
              Ответить
              • Потому что шарпеи не умеют в свободные функции. Ну и чтобы LINQ'подобные лесенки писать, не добавляя методы в сам класс.
                Ответить
                • >свободные функции
                  Што?

                  Чем плохо наследование?
                  Ответить
                  • Тем, что всё подряд ты в класс не втащишь. Это именно способ "добавить" метод в класс, не меняя ни его самого ни всех, кто его создаёт и юзает.

                    > Што?
                    Ты же питонист вроде, должен знать с чем их едят. Функции вне классов. Free function, non-member function.
                    Ответить
                    • Те не методы а просто функции? Но они там вроде и так есть.

                      >Тем, что всё подряд ты в класс не втащишь. Это именно способ "добавить" метод в класс, не меняя его.
                      Что конкретно туда не "втащишь"?
                      Ответить
                      • Ну вот есть у тебя стандартный String. Как в него втащить новый метод, который M$ туда не положил? А никак.

                        > Но они там вроде и так есть.
                        Нету их там, как и в жабе. Статиками эмулируют.
                        Ответить
                        • Статическими методами класса? Хз, я еще настолько хорошо сисярп не знаю. Мне бы с кем-то в нем гуйка поклепать.
                          Ответить
                      • Короче, это просто вот такой синтаксический сахар:
                        class Djihurda {
                           public static void hui(this Pizda p) { ... }
                        }
                        
                        Pizda p;
                        p.hui(); // эквивалентно Djigurda.hui(p)
                        И ничего больше.

                        Но для fluent-говна в духе LINQ в общем-то удобно.
                        Ответить
                        • Мой вопрос - зачем? Чем это лучше наследования?
                          Ответить
                          • Ну вот смотри. Есть у тебя IEnumerable. И ты хочешь, чтобы на нём можно было вызывать всякие сортировки, фильтры и прочую херню. В общем, хочешь запилить LINQ. С наследованием тебе придётся все эти методы втащить в IEnumerable, и он либо перестанет быть интерфейсом (а множественного наследования в шарпе, емнип, нету), либо заставит всё это запиливать в наследниках (что совсем пиздец).

                            Остаётся запилить пачку свободных функций (ну или статиков, раз у нас шарп) и писать SomeClass.sort(SomeClass.filter(x => x.name == 'hui', SomeClass.select(x => x.user, some))). Тоже какой-то пиздец.

                            И тут M$ придумывает экстеншн методы, которые по сути статики, но с синтаксисом от методов. И овцы сыты и волки целы.

                            Как-то так.
                            Ответить
                            • Это надо примеры смотреть как оно в линку профит дает.
                              Ответить
                              • Ну вот, скажем, String. Пусть там сделали trim, а trimLeft и trimRight не сделали. Я могу написать свои trimLeft и trimRight и вызывать их в том же стиле: s.trim(); s.trimLeft(). Иначе пришлось бы trim вынести в отдельную функцию, чтобы для симметрии было MyStringUtils.trim(s); MyStringUtils.trimLeft(s); Ну или унаследоваться и использовать свои строки. Пользы от экстеншнпитухов нет.

                                И вот, скажем, в библиотеке Ивана Денисова объекты типа DenisoffLoader возвращают String при загрузке данных. Придётся написать обёртку для его библиотеки только для того, чтобы подменить String на MyString только для того, чтобы написать s.trimLeft() вместо MyStringUtils.trimLeft(s). А можно запилить экстеншнпитух для String и жить счастливо.
                                Ответить
                                • Или new Mystring().trimLeft(); , а можно и как ты написал. Как-то же в жаве с этим живут. Вот я и спросил - зачем.
                                  Ответить
                              • Блин, ну почему ты заставляешь меня искать и описывать положительные стороны в языке, на котором я писать ближайшие лет 10 не собираюсь?

                                Профит в читаемости и только в ней. Сравни:
                                SomeClass.sort(
                                    SomeClass.filter(
                                        x => x.name == 'hui', 
                                        SomeClass.select(
                                            x => x.user,
                                            some)));
                                // vs
                                some.select(x => x.user)
                                    .filter(x => x.name == 'hui')
                                    .sort();
                                Ответить
                                • Я тебя не заставляю, не хочешь - проходи мимо.

                                  Удобство есть, но не придется ли за него где-то платить какими-нибудь конфликтами?
                                  Ответить
                        • А почему Djigurda.hui(p), а не Pizda.hui(p)?
                          Ответить
                          • См. выше. Кратко - всё в пизду не упихать, особенно если она интерфейс в духе IEnumerable.
                            Ответить
                            • Урок физики в церковно-приходской школе. Батюшка задаёт вопрос:
                              -скажите мне отроки, кОкое тело самое лёгкое?
                              один из учеников тянет руку.
                              -ну говори отрок Иохим.
                              -хуй, Батюшка.
                              -поясни!
                              -ну бывает хватает одной мысли чтобы он поднялся.
                              -хм, озорно, но верно. Скажите отроки, кОкое тело самое тяжёлое?
                              тот же ученик снова тянет руку.
                              -ну говори отрок Иохим.
                              -хуй, Батюшка.
                              -поясни!
                              -ну бывает никакой силой его поднять не удаётся.
                              -хм, озорно, но верно. А скажите мне отроки, кОкое тело самое.....
                              тот же ученик снова тянет руку.
                              -да помолчи ты отрок Иохим, а то ты мне так всю физику к хуям сведёшь!
                              Ответить
                            • class Djihurda {
                                 public static void hui(this Pizda p) { ... }
                              }
                              
                              class Bar {
                                 public static void hui(this Pizda p) { ... }
                              }
                              
                              Pizda p;
                              p.hui(); // чё выбрать?
                              Ответить
                              • Были бы кресты, был бы потрясающей убийственности UB, например.
                                Ответить
                                • > был бы потрясающей убийственности UB, например

                                  Ну вот не надо, крестокомпилятор ругается, когда не может выбрать единственно-правильную функцию.
                                  Ответить
          • Кстати, в следующих плюсцах тоже планируют такую штуку запилить. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf
            Ответить
            • Это они скорее всего опять из D взяли
              https://dlang.org/spec/function.html#pseudo-member
              Ответить
            • Очень надеюсь что выберут [4]. Может для концептов и для хардкорного шаблонного программирования это и хуже, но половине программистов не придётся переписывать код или помнить ещё одну ебанутую особенность С++.
              Ответить
              • А что там в варианте 4?
                Ответить
                • f(x, ...) будет рассматривать x.f(...) только в случае, если никакая свободная функция не подошла и наоборот.

                  Ещё есть "всегда предпочитать члены/свободные функции" (очень много веселья с случайным рекурсивным вызовом при сборке старого кода новым стандартом)

                  И "Рассматривать члены и свободные функции равнозначно, выбирать лучшую разрешением перегрузки".

                  Главная проблема, это код в стиле:
                  struct foo {
                      void bar(); //mutates
                  }
                  
                  foo bar(const foo& in)
                  {
                      return foo(in).bar();
                  }
                  Ответить
      • Васе пригорело и он навъебывал минусов?
        Ответить
    • бывает полезно при портировании, например.

      а тут, может, имя не понравилось )
      Ответить
    • Хуйня, не считая опечатки совершенно рабочий код.
      Это супер удобно, особенно в небольших проектах.
      Ответить
      • Приведи плз пример где это прям супер удобно?
        Имхо это код ради кода. Масло масляное. Никакого толку от подобного кода нет, а программистам, которые его пишут, руки надо рубить по самые локти.
        Ответить
        • Начнем издалека. Разумеется с точки зрения архитектуры экстеншен методы избыточны. Все, что можно засунуть в экстеншен метод можно было бы хранить в каком-то красиво названном классе и даже не статике и даже закопать поглубже и поближе к бизнес логике.

          Но очень скоро окажется, что если в одном месте нужно прибавлять к текущей дате несколько рабочих дней, то и в других местах это сделать нужно. Такой код, на прямую не относящийся к конкретной бизнес логике либо будет задублирован, либо в итоге всплывет в какой-то сквозной DateHelper, которым много кто будет хотеть пользоваться. Более хорошим примером, пожалуй, будет склонение слова в падежах – с легкостью может оказаться полезным в любом месте.
          Ответить
        • И тогда
          DateHalper dateHelper = new DateHalper()
          DateTime newDate = dateHelper.AddWorkDays(oldDate, 3);


          в то время, как если мы хотим прибавить 3 обычных дня мы напишем просто
          DateTime newDate = oldDate.AddDays(3);


          Ну как бы в целом то похуй, но AddDays удобно и oldDate.AddWorkDays(3) удобнее и чище.
          Мы не могли добавить нужный метод в DateTime, но экстеншен метод нам помог.

          Теперь возвращаемся class StringExtensions и IsNullOrEmpty.
          Во первых автар скопипастил только 1 метод, а на самом деле в StringExtensions к бабушке не ходи их там дохуя.

          мы же проверяем строку на пустоту не просто так, а как правило хотим еще что-то сделать. Например для имени мы хотим сделать Trim, потом все буквы слов сделать малкенькими, а первые буквы большими (мы знаем что имена русские) чтобы из "КОЗЛОВА " получилось "Козлова".

          вот такую хуйню и заебись складывать в экстеншен метод.
          lastName = input.CleanupName();

          если input нулл - то нуллРеференс не будет т.к. код внутри экстеншена это почистит, получим или имя или нулл.

          или например input.Trim() заменяет
          string.IsNullOrEmpty(input) ? null : input.Trim()


          Теперь, когда в c# 6.0 есть нулл пропагейшен (null propagation)
          такое можно записать как input?.Trim()
          и вытворять такие вещи: product?.Price?.ToString("#.00")

          но экстеншен методы всеравно остаются удобными.
          Ответить
          • вопрос то был

            esromhaz в http://govnokod.ru/19174#comment310155 написал:
            >> Приведи плз пример где это прям супер удобно?

            А тут словоблудие, словоблудие, еще словоблудие.

            Данный экстеншен в данный момент не несет никакой пользы кроме эстетической

            ибо пока 6 шарп начнут повсеместно юзать... Большинство контор дальше 3 так и не зашли
            Ответить
            • ну ок, "супер удобно" по отношению к этому методу не совсем то, однако в ифах, читать код в таком виде, как мне кажется, удобнее:

              if (myObject == null && !otherStuff.NestedStuff.Text.IsNullOrEmpty())
              {
                  return otherStuff.NestedStuff.Text;
              }

              читаешь не с string.IsNullOrEmpty а потом otherStuff.NestedStuff,
              а сразу с предмета выражения: otherStuff.NestedStuff....

              я хотел сказать, что это просто обычный код.
              Ответить
              • Не вижу принципиальной разницы между
                покорми собаку
                и
                собаку покорми
                Ответить
                • Тогда чуть корректнее привести аналогию:
                  Покорми соседний дом, дядя Ваня, собака
                  И
                  Соседний дом, дядя Ваня, собака, покормить

                  Настаиваю, что разница есть, хоть и незначительная.
                  Ответить

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