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

    +126

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    double fact(int value)
            {
                switch (value)
                {
                    case 0:
                        return 1;
                        break;
                    case 1:
                        return 1;
                        break;
                    default:
                        return value * fact(value - 1);
                        break;
                }
            }

    Вычисление факториала

    Запостил: zzANDREYzz, 04 Апреля 2012

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

    • показать все, что скрытоВ чём ГК?
      Ответить
      • Видимо, в том, что case 1: не нужен... (ну а в реальном приложении еще нужно было бы проверить аргумент и бросить исключение, если < 0)
        Ответить
        • показать все, что скрытоОптимизация.
          Конечно, case 0 и case 1 можно было бы объедениться в единый блок.
          В остальном всё верно.
          Ответить
          • > Оптимизация
            отлично сочетается с рекурсивным вычислением факториала
            гамма функция рулит
            Ответить
            • а как считать гамму?
              Ответить
              • http://gcc.gnu.org/onlinedocs/gfortran/GAMMA.html
                Ответить
                • а для бесфортранных?
                  Ответить
                  • специально для тех, кого на гугле забанили
                    http://www.boost.org/doc/libs/1_41_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_gamma/tgamma.html
                    Ответить
                    • горочка красивая для неспециализированного unchecked_factorial
                      http://bit.ly/HTmdFi
                      Ответить
                      • А чё на крестошаблонах массив не заполнить, чё руками?
                        Ответить
                        • видимо, время компиляции экономят
                          Ответить
                        • на каких крестошаблонах ты собрался заполнять
                          93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
                          Ответить
          • Какая еще оптимизация? Факториал можно и нерекурсивно написать, вот вам и оптимизация. Во вторых тут дабл еще почему то.
            Ответить
            • Дабл чтобы не переполнялось при эн больше 13
              Ответить
        • Это и есть древний способ обработки исключений switch блоками на киллометр, а где тут C# собственно? А, value.
          Ответить
      • >В чём ГК?
        Не используется LINQ.
        Ответить
        • показать все, что скрытоололо ололо
          Ответить
        • А что вы травите? ЛИНКВ удобная тема.
          Ответить
          • Никто не никого тгавит.
            Просто поциенты считают, что Linq - панацея от всего. В том числе от отсутствия головного мозга.
            И пихают оный где нужно и где не нужно.

            Циклы, например - не нужны. Есть where и лямбды.
            Треды не нужны - есть asParallel. Алгоритмы - не нужны, есть Linq. Мозг не нужен - пусть за меня думает Microsoft.

            >ЛИНКВ удобная тема.
            Правильно. А факториалы нужно считать рекурсивно через switch.
            Ведь умный конпелятор сам сделает из кейсов конфетку.
            Ответить
            • на самом деле Microsoft виноваты в привлечении подобной клиентуры
              Ответить
            • А что, я считаю, что .foreach - это красивее, чем императивное полотно с циклом. Мне нравится стиль ЛИНКВА.
              Ответить
              • То есть порождение анонимной функции, верней делегата, который потом вызывается в цикле тебе кажется однозначно красивей, чем обычный foreach - C#, for ~ in - js итд.

                То есть паттерн Стратегия с динамическим связыванием и вызовом разных функций с идентичными сигнатурами, однозначно красивей, чем императивный оператор switch?

                А функция-предикат однозначно красивей, чем императивный if?

                >Мне нравится стиль ЛИНКВА.
                И сахар в виде extension-методов тебе тоже нравится, когда вызывается как бы метод объекта, а на самом деле это какой-то левый статический метод.
                Это тоже красиво?!
                Ответить
                • Да.
                  Ответить
                  • Но позвольте, у меня все ходы записаны.
                    http://www.gamedev.ru/flame/forum/?id=147021&page=7

                    Или надо написать тривиальный case (оператор множественного выбора).
                    Нормальный человек пишет case.
                    Поциент, больной оопиозом головного мозга, напишет по одному классу на каждую ветку этого case, а сам case заменит на вызов виртуального метода.
                    Для каждого case - свой набор классов.
                    Кол-во классов у такого поциента может быть астрономическим, код сам по себе пухнет из-за тормозных абстракций на ровном месте.
                    Ответить
                    • Да ты же меня подловил.
                      Для полноты слива мне осталось только добавить "я всё это учудил для того, чтобы потроллить".

                      На самом деле я сторонник KISS. Но .where и .foreach таки красивее чем цикл.

                      А .AsParallel ВАЩЕ ОХУЕННО!!!
                      Ответить
            • Идеи filter, map, reduce и многих других функций высшего порядка настолько естественны и элегантны, что критиковать их у меня язык не поворачивается.
              В 90% кода приложений, с которыми я работаю, разница в производительности цикла и функции высшего порядка не имеет значения (вызов веб-сервиса порой занимает пару секунд, какой смысл экономить на спичках?), и я скорее отдам предпочтение функциям высшего порядка.
              Функции высшего порядка не отменяют необходимости анализа алгоритмов, и уж сложности они точно не прибавляют (немного меняют константы, но не порядок).
              Преподносить LINQ как какую-то уникальную технологию - смешно, ведь все идеи, лежащие в его основе, известны уже десятки лет (всё это довольно детально описано в SICP). Но и ничего плохого в нём я не вижу.
              Ответить
              • >Преподносить LINQ как какую-то уникальную технологию - смешно
                Именно.

                >и я скорее отдам предпочтение функциям высшего порядка.
                Но это совсем не повод совать функциональщину где попало. Даже в тех местах где обычный цикл короче и эффективней.

                И не нужно забывать про оверхед (в жабе вовсе чудовищен, но и в более продвинутом шарпе его хватает), когда для написания кастомной логики нужно создавать дополнительные объекты типа делегатов, extension-методов и других вспомогательных сущностей.
                Ответить
                • Да, в java оверхед слишком часто перевешивает преимущества. Тем не менее, иногда встречаются места, где очень много однотипных, лишь немного отличающихся операций. И тут я имплеменчу несколько com.google.common.base.{Predicate, Function}, оформляю их в виде синглтонов и использую Lists и Iterables. Так циклы на восемь - десять строк превращаются в одну строку, реюзабилити повышается, и смысл кода становится гораздо более очевидным.
                  Ответить
                  • >Тем не менее, иногда встречаются места, где очень много однотипных, лишь немного отличающихся операций.
                    Тут, безусловно, такой подход легитимен. Собственно для увеличения энтропии кода он и создан.
                    Но и злоупотреблять не стоит, ибо функциональный код иногда читается хуже, чем императивный.
                    Ответить
                    • > ибо функциональный код иногда читается хуже, чем императивный
                      С этим я и не спорю. Хотя компактность, как правило, повышается. Здесь, как обычно, на помощь приходит чувство меры.
                      Ответить
                      • Ну не знаю, мне функциональный код и писать и читать легче.
                        Ответить
                        • И мне обычно тоже. Но ведь я не один в проекте работаю, ещё примерно 80 человек. Сколько из них вообще слышали о FP? единицы. А сколько чувствуют себя уверенно с этой парадигмой?.. Кто будет править код, когда я перестану работать в этом проекте? В итоге никто ведь не будет разбираться, допишут кривых императивных костылей и пойдут пить пиво.
                          Ответить
                          • Верно. Про то я как раз хотел написать, что функциональное очевидно не всем.
                            И про меру тоже правильно сказано.

                            Короче, новомодная функциональщина как и когда-то ооп, полезны не всегда.
                            Как я уже говорил выше: считать linq серебрянной пулей - нельзя.
                            Да и вообще зря они в изначально сбалансированный структурно ооп-шный язык вносят спорные улучшения.

                            Как по мне, то шарп теряет свою стройность, которая была в версии 2.0 и потихоньку превращается в эзотерику подобную С++, где напихано всего и помногу.
                            Адептам пейсать всё на linq порекомендовал бы пересесть на какой-то функциональный язычок, где императивно кодить попросту нельзя.
                            Ответить
                            • У них там вроде OCaml.NET F# есть, проталкиваемый мелкософтом.
                              Ответить
                              • Собственно на няго я намякал.
                                Но мне больше по нраву православный Nemerle.
                                Ответить
            • это же прям про тараса со его быдлодельфяшечкой
              Ответить
    • 1)Лишние брейки.
      2)Нет проверки аргуентов (уже назвали).
      4)Нужно объединить кейсы 1 и 0 (уже назвали).
      5)Лучшеб не выпендривался и написал не рекурсивный алгоритм.
      6)Добавил бы мемоизацию аля массив.
      Ответить
    • Pattern Matching доставил
      Ответить
    • и еще момент: double не придает ли коду очарования потери точности? :-)
      Ответить
    • показать все, что скрытоvanished
      Ответить

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