1. Pascal / Говнокод #8617

    +145

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    if c = 'y' then 
    begin 
      Writeln('Yes'); 
    end else 
    if c = 'n' then 
    begin 
      Writeln('No'); 
    end;

    Вот это кака... http://delphisources.ru/forum/showthread.php?t=19000

    Запостил: Nikitiy_II, 23 Ноября 2011

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

    • А потом из-за таких на нас гонят.
      Ответить
      • А как бы вы это написали?
        Ответить
        • Касеофом
          Ответить
        • case
          if, конечно, в данном случае прокатит, но что будет, когда проверок >=3, больше 10?
          Ответить
          • > проверок <=3 больше 10
            oh, shi
            Ответить
            • Чем вам >= не угодил? Вроде про delphi пишем.

              Для большей доходчивости: проверок >=3, или даже >10?
              Если совсем по-русски: а если проверок будет больше трёх или даже больше десяти, так и будем if'ы лепить?
              Ответить
          • Но ведь их две, что значит "что будет"? Их, как видно по смыслу, две.
            Или тогда не выводить результат нужно, а возвращать. Вдруг надо будет куда-нибудь его передать, сложить с другой строкой, отрендерить красиво?
            Ответить
            • "Их, как видно по смыслу, две."
              Нормальные герои всегда идут в обход?
              "Вдруг надо будет куда-нибудь его передать, сложить с другой строкой, отрендерить красиво?"
              А чем вам begin-end/return внутри case не угодили?
              Ответить
              • > Нормальные герои всегда идут в обход?
                Представлен код, по нему видно, чего хотел добиться автор. Есть иные варианты?

                > А чем вам begin-end/return внутри case не угодили?
                Вот и я про то же. Сначала добавить кейс на случай "мало ли чего", потом выделим пиксельный кусок в отдельную функцию по той же причине. А автор даже и не думал, что ему это может понадобиться.
                Оверинжиниринг, вот что.
                При двух вариантах большой разницы между ифом и кейсом нет. При 100 вариантах и кейс будет не в тему, давайте сразу на такой случай рассчитывать?
                Ответить
                • "Представлен код, по нему видно, чего хотел добиться автор. Есть иные варианты?"
                  Хорошая привычка для программиста думать о том, что этот код придётся менять и поддерживать, но это понимаешь только побившись головой об стенку. If-else естественен для простых операций типа да/нет, а тут ещё возможны другие варианты: a-z. Это явно больше, чем да/нет.
                  "При 100 вариантах и кейс будет не в тему"
                  Как это не в тему?
                  Ответить
                  • практика показывает, что в лучшем случае добавиться maybe
                    Ответить
                  • А ты будешь копипастить по сто раз
                    x: begin end
                    x+1: begin end
                    ?
                    Сомневаюсь.
                    Ответить
                    • Тут уже по месту - можно сократить - сократим, нет - case. И кроме целых бывают ещё и строки, и комплексные числа.
                      Ответить
            • > по смыслу две
              Ну тогда баз второго if`а можно обойтись.
              Ответить
        • (def answers {:y "Yes", :n "No"})
          (defn yes-no [c] (answers (keyword (.toLowerCase c))))
          Ответить
          • Кложура? Если совпадения нет, не упадет?
            -- just for fun
            expand :: Char -> Maybe String
            expand = flip lookup [('y',"Yes"), ('n',"No")]
            Ответить
            • Я понял, понял зачем нужны эти все функциональные языки, и почему они не используются в качестве промышленных.

              А нужны они, чтобы решать такие вот задачи.
              Ответить
              • А вы пробовали ХМонаду? Очень (ну может несколько преувеличиваю) удобный wm.

                Pandoc, Gitit, парсеры, математика (если есть биндинги)... Есть даже утилита типа socat (только базовый функционал) для 0MQ.
                Ответить
                • Хорошо, что Darcs не вспомнили. Ради интереса почитал теорию, задвигаемую автором (алгебра патчей), мне она кажется немного бредовой. А в реальной жизни сплошные тормоза, экспоненциальный рост при мёрже.
                  Ответить
                  • Были проблемы с merge. Некоторое время не советовали им пользоваться.

                    К тому же, его все равно нельзя назвать уникальным, есть же git/hg (и много проектов на github). Ограничения компиляторов на архитектуру (не под все есть) - тоже не в плюс портабельности.
                    Ответить
              • Ну, на лиспе много чего написано.
                Назвать, к примеру, Erlang не промышленным язык не поворачивается...
                Ответить
              • Да ладно, половина java-кода на моей работе - перекладывание одних типов полей в другие и всяческая агрегация. Я это свитчи и циклы уже видеть не могу.
                Ответить
                • типичный жаба-код, собственно как и весь enterprise-web-application-soft - это не программирование вовсе.

                  это переписывание данных из одного места в другое, с другого в третье итд

                  (с формы в переменные js, c переменных js переписать в xml, передать постом на страницу, из страницы передать в интерфес, из интерфейса данные xml переписать в сущность, из сущности скопировать в базу, из базы обратно переписать в сущность, потом скопировать в другую сущность, далее переписать из этой сущности в json итд),

                  В итоге выдача их (с необходимыми проверками доступа и валидности).
                  Ответить
                  • Куча кода с одинаковым смыслом, но немного разными типами, который никаким приличным образом не приведёшь к общему виду. То, что на java занимает 20 строк, на Clojure или Scala занимает 2. И от этого у меня баттхёрт.
                    Люди, не изучайте ФЯП - от них баттхёрт
                    Ответить
                    • >Куча кода с одинаковым смыслом, но немного разными типами, который никаким приличным образом не приведёшь к общему виду.

                      Именно!
                      Причем ООП зачастую еще усложняет и добавляет ненужные промежуточные стадии.
                      А чем больше в проекте абстракций, тем проще вводить новые, ненужные паттерны, которые снова просто копируют данные - всякие там декораторы, фасады итд..
                      Ответить
                      • > чем больше в проекте абстракций
                        Вот об этом всё ФП. Оно как бэ говорит нам "Да вы ебанулись все с этими объектами и новыми абстракциями". Тут главная идея: пиши простые маленькие независимые (желательно, чистые) функции, а язык позволит тебе комбинировать их бесчисленным количеством способов.

                        Взять, к примеру, шаблонизаторы для html. В Java желательно использовать jsp, а чтобы комбинировать view нужно прикручивать Tiles/переходить на jsf с facelets.

                        В Lisp тебе достаточно написать десяток макросов (страница кода) для удобных генерации и вывода тегов в поток, и вуаля, у тебя есть язык шаблонов. Который на самом деле - обычный Lisp, со всеми вытекающими.

                        View - это функция, принимающая на вход таблицу параметров (и, быть может, поток). Хочешь композитный view - напиши простую функцию, принимающую на вход помимо таблицы параметров ещё и таблицу функций, отрисовывающих отдельные области.

                        В результате - никаких лишних абстракций, обошлись функциями + микро DSL для отрисовки html-тегов.
                        Ответить
                    • А зашаблонить, свести к универсальным методам, принимающим указатели на функции?
                      Ответить
                      • В Java нет вразумительных средств кодогенерации, коими из коробки обладают C++ и Lisp. Указателей на функции там тоже нет. Есть ссылки на методы, но использовать их в промышленном коде не стоит.
                        Ответить
                        • >Есть ссылки на методы, но использовать их в промышленном коде не стоит.
                          Почему не стоит?
                          Ответить
                          • roman-kashitsyn, ответе, если не сложно?
                            Ответить
                            • Во-первых, для их получения нужна работа с рефлексией, а это всегда довольно громоздкие конструкции и отлов checked-исключений. Во-вторых, компилятор тут уже ничего не гарантирует: при неаккуратном рефакторинге можно сломать чужой код. В третьих, рефлективные вызовы методов гораздо медленнее обычных.
                              Ответить
                              • >всегда довольно громоздкие конструкции и отлов checked-исключений

                                Не всегда. Если вынести работу с рефлексией в библиотечный класс с удобными обертками.

                                >рефлективные вызовы методов гораздо медленнее обычных
                                Груви медленей жавы в 100 раз (вполне возможно и из-за рефлексии), скала в 5 раз.

                                Короче спорное утверждение.
                                Злоупотреблять однозначно не следует.
                                Ответить
                                • Тому же Спрингу без рефлексии вообще никак. В моём текущем проекте за вызов методов через рефлексию я бы руки оторвал.

                                  invokedynamic нас всех спасёт, если не успеет утянуть на дно бремя обратной совместимости.

                                  > скала в 5 раз
                                  "спорное утверждение"
                                  http://shootout.alioth.debian.org/u32/scala.php
                                  Памяти обычно больше требует, это да.
                                  Ответить
                                  • >Спрингу без рефлексии вообще никак
                                    Насколько я знаю тулзы для работы с бинами больше используют не рефлексию, а интроспекцию - она быстрее (возможно потому что где-то в недрах явы хитро кешируется).
                                    Ответить
                                    • Introspector возвращает BeanInfo, которых позволяет легко посмотреть все свойства и методы. BeanInfo кэшируются, при повторном запросе поучим тот же инстанс.
                                      Однако в конечном счёте всё равно придётся делать тормозной Method.invoke().
                                      Ответить
                    • >Люди, не изучайте ФЯП - от них баттхёрт
                      +100500
                      Писал на няшной сишечки и батхерта не ведовал. Но только стоило... Ну ты понел.
                      Ответить
                    • >> Люди, не изучайте ФЯП - от них баттхёрт

                      Именно поэтому я за «PHP».
                      Ответить
                • >Я это свитчи и циклы уже видеть не могу.
                  Меня тоже от них тошнит. Достала эта императивщена.
                  Ответить
            • > Если совпадения нет, не упадет?
              user=> (yes-no "y")
              "Yes"
              user=>(yes-no "xz")
              nil
              Ответить
          • ЛNСПер в треде! Все в lambda-функции!
            Ответить
          • >{:y "Yes", :n "No"}
            Фууу. Турнирный оператор.
            Ответить
    • Во блин, не тот код скопипастил(
      Ответить

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