1. PHP / Говнокод #13703

    +165

    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
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    function register()
    {
        if (!empty($_POST)) {
            $msg = '';
            if ($_POST['user_name']) {
                if ($_POST['user_password_new']) {
                    if ($_POST['user_password_new'] === $_POST['user_password_repeat']) {
                        if (strlen($_POST['user_password_new']) > 5) {
                            if (strlen($_POST['user_name']) < 65 && strlen($_POST['user_name']) > 1) {
                                if (preg_match('/^[a-z\d]{2,64}$/i', $_POST['user_name'])) {
                                    $user = read_user($_POST['user_name']);
                                    if (!isset($user['user_name'])) {
                                        if ($_POST['user_email']) {
                                            if (strlen($_POST['user_email']) < 65) {
                                                if (filter_var($_POST['user_email'], FILTER_VALIDATE_EMAIL)) {
                                                    create_user();
                                                    $_SESSION['msg'] = 'You are now registered so please login';
                                                    header('Location: ' . $_SERVER['PHP_SELF']);
                                                    exit();
                                                } else $msg = 'You must provide a valid email address';
                                            } else $msg = 'Email must be less than 64 characters';
                                        } else $msg = 'Email cannot be empty';
                                    } else $msg = 'Username already exists';
                                } else $msg = 'Username must be only a-z, A-Z, 0-9';
                            } else $msg = 'Username must be between 2 and 64 characters';
                        } else $msg = 'Password must be at least 6 characters';
                    } else $msg = 'Passwords do not match';
                } else $msg = 'Empty Password';
            } else $msg = 'Empty Username';
            $_SESSION['msg'] = $msg;
        }
        return register_form();
    }

    Из рассылки PHPWeekly: "A Clean and Secure Open Source PHP Login Script"
    https://github.com/panique/php-login/blob/master/0-one-file/index.php#L98

    Что-то уж очень сильно "Clean".

    Запостил: brevis, 29 Августа 2013

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

    • if ()
       if ()
        if ()

      То ли про && не слышал, то ли он в пыхе поломаный, то ли автор хотел проверить, докуда может дойти лесенка.
      Ответить
      • > То ли про && не слышал
        Так там же внизу else еще есть. И они везде разные. && тут ничем не поможет.

        Тут нужны нормальные валидаторы :)
        Ответить
        • В таких случаях обычно инвертируют условие + return

          if (!$_POST['user_name']) {
              return 'Empty Username';
          }


          Или (пых там может в исключения?):

          if (!$_POST['user_name']) {
              throw KokokoException('Empty Username');
          }
          Ответить
          • Кто тут возмущался ботам-минусаторам?
            Ответить
          • Это тоже не очень хорошая практика. Обычно считается что у функции должна быть одна точка выхода. Т.е. return посреди функции не есть гуд.
            Тут варианта два
            - либо кидать исключения.
            - либо хранить состояние ошибки в переменной и проверять ее при дальнейших действиях
            Ответить
            • > считается что у функции должна быть одна точка выхода
              Тогда исключения использовать нельзя, ведь выброс исключения - вторая неявная точка выхода.
              Ответить
            • > считается что у функции должна быть одна точка выхода
              Сектант-одновозвратник в треде!

              Говорить о том, что лишние точки возврата нежелательны, но при этом юзать throw это как-то странно ;) Тем более исключения могут вылететь в одной из вызываемых функций, и тем самым спровоцировать неожиданную точку возврата...

              Да и нету ничего плохого в нескольких точках выхода. Так же как и в goto. Просто надо во всем знать меру, а не слепо следовать своей религии. Например, лично для меня, зачастую второй return удобней, чем лишний флаг/проверка (которые так любят лепить одновозвратники), читабельность от этого только улучшается.
              Ответить
              • а еще в некоторых языках есть контракты кода - тоже своего рода точки выхода, очень удобные штуки
                Ответить
            • >Обычно считается что у функции должна быть одна точка выхода. Т.е. return посреди функции не есть гуд.
              Что, простите?
              Ответить
              • Что то в стиле

                public float SomeShit(float  a)
                        {
                            var hasError = a < 0;
                            // мучитильные вычисления неведомой зверушки
                            return hasError ? -1 : a;
                        }

                )))
                Ответить
                • фу, так пишут только заедушные сектанты-одновозвратники :)
                  Ответить
                • Не я слышал про это, но не думал, что этим кто-то пользуется.
                  Ответить
                  • дураков много)
                    Ответить
                  • Есть даже языки с реализацией этого правила.
                    Если больше одного ретурна в одном скоупе, то даже не скомпилится.
                    Как минимум, у M$ в T-SQL такое есть. Одна функция - один ретурн :(
                    Ответить
            • >. Обычно считается что у функции должна быть одна точка выхода
              Это теми считается кто не умеет их готовить. return отлично видно в функциях размером 20-25 строк.
              Ответить
              • Ну одепты одновозвратничества приводят еще такой довод: если нужно освободить какие-то ресурсы или сделать что-то еще при выходе, то с одной точкой возврата это сделать легче.

                Для языков, в которых нету ни RAII ни finally, эта фраза даже имеет смысл. В той же сишке это правило не от хорошей жизни соблюдают...

                Для высокоуровневых языков же одновозвратничество обычно только усложняеет код, и превращается в банальное флагоёбство или лишние инварианты (да и, как я писал выше, исключения добавляют еще кучу потенциальных точек выхода, которые одновозвратнику придется учесть с помощью горы try'ев).

                P.S. Если здесь есть одепты одновозвратничества, которые хотят оспорить мои слова - пожалуйста, приводите примеры кода (на высокоуровневом языке типа c++, java и т.п., не на сишке), и я с удовольствием с вами похоливарю.
                Ответить
                • А, так это не хороший стиль, а СИШКОПРОБЛЕМЫ (байтоёбопроблемы, выбрать нужное).
                  Ответить
                  • > СИШКОПРОБЛЕМЫ
                    Ну не только сишко. Общая проблема языков, в которых нет RAII, finally, или их аналогов.

                    Ну хорошего стиля тут, имхо, совсем немного. Обычно наоборот, в высокоуровневых языках код с одним return'ом смотрится хуже, чем с парой-тройкой. А там где получается понятней - там скорее всего гигантская функция на 50-100 строк.
                    Ответить
                    • Какие это из языков со сборкой мусора? И что за RAii?
                      Ответить
                      • Язык со сборкой мусора и исключениями без finally или его аналогов, имхо, будет вообще неюзабельным, поэтому вроде как во всех есть.

                        А RAII (resource acquisition is initailization) это из крестов. Когда объект, управляющий каким-то ресурсом типа файла или сокета, закрывает его в своем деструкторе.
                        Ответить
                        • >Язык со сборкой мусора и исключениями без finally или его аналогов, имхо, будет вообще неюзабельным

                          Почему же? можно дублировать код в try и catch блоках. Через анус, но сработает
                          Ответить
                          • В том и дело, что через анус... В файналли действие исполняется и по исключению, и по выходу, а тут придется копипастить джважды.
                            Ответить
                            • Я к тому что по сути finally - это сахарок

                              Всегда найдутся упоротые^W люди, которые предпочтут явно продублировать код освобождения ресурса)
                              Ответить
                • Для отладки все равно всегда приходится переписывать так, чтобы функция возвращала в самом конце. Потом, я не вижу смысла переписывать в уродские if (foo) return; и т.д.
                  Те, кто ставят много return в одной функции - не научились пользоваться отладчиком.
                  Ответить
                  • > if (foo) return
                    Предпочитаете добавить лишний уровень отступов? :)

                    > переписывать так, чтобы функция возвращала в самом конце
                    Ради бряков похабить код?

                    > не научились пользоваться отладчиком.
                    В том же эклипсе есть exit брекпоинты, которые срабатывают на return'ах... И всяко они есть не только там...
                    Ответить
                    • > Предпочитаете добавить лишний уровень отступов? :)
                      Или может быть поперчить код флагами? :)
                      Ответить
                    • Наоборот, код уродский именно когда в нем много разных точек возврата. Это просто неряшливо / выглядит непродумано. Кроме отладки - рефакторинг, если нужно вернуть что-то другое, то нужно менять в нескольких местах.
                      Множественные точки возврата - они как правило от неумения нормально сотавить контракт для функции / неумения описать для самого себя, что именно функция должна принимать и возвращать. Или C-подобного недоразумения, где "функции" вместо того, чтобы что-то возвращать чего-то там меняют в аргументах.
                      Ответить
                      • Приведите, пожалуйста, пример функции, которая по вашему мнению оформлена красиво, но с несколькими возвратами она смотрелась бы по-уродски.
                        Ответить
                    • Мне где-то недавно попадалась статья / исследование, где на примере программы на Питоне исследовали как программисты читают код, сколько времени занимает анализ каких конструкций, в каком порядке код просматривается и т.д. С точки зрения человека читающего код неожиданный возврат = разрыв шаблона. Вводит в ступор, заставляет вернуться к началу функции, перечитать и т.д. Это все равно что изменить грамматику в предложении таким образом, чтобы изменение стало понятно только после того, как человек прочитал уже достаточно далеко за это изменение. Типа как в немецком языке приставки от глаголов внезапно обнаруживаются в конце предложения, особенно западло, когда предложение длинное, и нужно возвращаться к началу и пытатьтся выяснить от какого глагола эта приставка.
                      Ответить
                      • Ну ок, давайте возьмем такую простую функцию, как indexOf (предположим, что такой функции в либе еще нет).
                        int indexOf(Object needle) {
                            for (int i=0; i<count; i++) {
                                if (haystack[i] == needle)
                                    return i;
                            }
                            return -1;
                        }
                        Перепишите, пожалуйста, ее в одновозвратном стиле.
                        Ответить
                        • Вот, да, хорошая иллюстрация того как плохой подход к написанию програм приводит к плохим результатам.
                          Что такое "-1"? Почему возвращается именно эта константа, а не -2 например?
                          Кнут, например, считает, что нужно возвращать первый индекс за пределами массива, что имеет определенный смысл, в то время как отрицательные индексы - просто бред, а кроме того заставляют расширить тип возвращаемых значений от только беззнаковых до знаковых + беззнаковых.

                          Более того, такой код делает предположение об однопоточности приложения, не давая ему возможности воспользоваться параллельным выполнением / затрудняя поиск инварианта, который бы хорошо распараллелился. (Скорее всего, что чтобы распараллелить поиск массив будет разделен на части и поиск будет в каждой из них, с последующим выбором наименьшего результата.)
                          Ответить
                          • Ок, как бы вы переписали код, с учетом ваших замечаний?
                            Ответить
                            • Это никакой не индекс за пределами массива. Индексы массива могут быть только неотрицательными.
                              Как бы переписал? Вместо первого return - break, вконце - return i. i соответственно, нужно было бы объявить за пределами цикла.
                              Ответить
                              • > Вместо первого return - break
                                break не карается одновозвратниками? (не вброс)
                                Можно обернуть тело функции в цикл и пользоваться break.
                                Ответить
                              • А, понял про индекс за пределами массива. Т.е. если массив от 0 до 9, то мы возвращаем 10.
                                Ответить
                                • > break - ну не возвращает же из функции, претензий нет. К нему могут быть претензии с других позиций, но с этой - все нормально.
                                  > 10 - да, именно.
                                  Ответить
                                  • >> 10 - да, именно.
                                    Здесь есть проблема - в отличие от специального значения, на эту десятку довольно сложно проверять. Вдруг мы не знаем длину массива в точке, в которой будет проверка?

                                    Поэтому мне все-таки ближе подход шарпа и хаскеля. В шарпе есть "nullable<T>", он же "T?", добавляющий специальное значение null к типу T. В хаскеле похожий тип Maybe T, имеющий значения Just t и Nothing.
                                    Ответить
                                    • Такой вдруг бывает только в недоязыках, типа Си. Да и там в большинстве случаев компилятор знает какого размера массив. А если не знает - то, я думаю, это повод задуматься о том, как бы вы искали в нем что-нибудь в первую очередь.
                                      Ответить
                                      • > компилятор знает какого размера массив
                                        Кроме простых случаев, когда размер массива вшит в коде - нет, не знает. Откуда компилятору знать значения, которые будут известны только в рантайме?
                                        Ответить
                                        • Ну а как искать-то в массиве, не зная где он заканчивается?
                                          Ответить
                                          • > Ну а как искать-то в массиве, не зная где он заканчивается?
                                            В рантайме то его длина известна...
                                            Ответить
                          • > Почему возвращается именно эта константа,
                            Потому что это, позвольте процитировать вас и Кнута, первый индекс за пределами массива.
                            Ответить
                      • >С точки зрения человека читающего код неожиданный возврат = разрыв шаблона

                        То есть программа должна выполняться полностью даже если на начальном этапе ясен ответ? Люди так не мыслят
                        Например, едет человек в магазин, на встречу ему идет знакомый и говорит, что магазин закрыт. Что сделает человек? Упадет закатив глаза? Так сказать "прервет операцию похода в магазин". Ихмо для человека это естественно
                        Ответить
                        • Откуда такие шаловливые мысли? Нет, программа должна быть построена так, что ее выполнению легко следовать, не возвращаясь к уже прочитаным частям. Когда у нас есть лишняя точка выхода, то после нее может легитимно возникнуть вопрос "а что если мы сейчас делим на 0?", и не найдем гарда вокруг текущего блока, который бы нам тут же гарантировал, что вариант с 0 исключен, и вместо того, чтоби искать линейно "вверх по иерархии блоков", нам нужно будет искать по всему телу функции проверяя а не закончилась ли она внезапно где-то хз. где.
                          Ответить
                  • P.S. Если здесь есть одепты одновозвратничества, которые хотят оспорить мои слова - пожалуйста, приводите примеры кода (на высокоуровневом языке типа c++, java и т.п., не на сишке), и я с удовольствием с вами похоливарю.

                    Напишите, пожалуйста, какой-нибудь код в одновозвратном стиле, который убедит меня в превосходстве этого стиля.
                    Ответить
                    • Да, и мне хотелось бы посмотреть, как перепишут код вроде этого
                      http://golang.org/src/pkg/io/ioutil/ioutil.go?s=3159:3210#L87
                      без множественного return (исключения - не go-way).

                      > кто ставят много return в одной функции - не научились пользоваться отладчиком
                      кто ставит один - не научился не пользоваться отладчиком?
                      Ответить
                      • Не научился потому, что отладчик - имеет такой же интерфейс как и любая другя программа. Если человек сделал так, что у него вместо одой кнопки выполняющей одну функцию в программе есть Х таких кнопок ничем друг от друга не отличающихся, то он просто дурак / "китайский" программист, который добивается желаемого эффекта усиленым ручным трудом и бесконечными повторениями.
                        Ответить
                        • я ничего не понял. конкретней, пожалуйста.
                          Ответить
                          • Ну учиться не делать что-то полезное напрямую связаное с уровнем профессионализма в выбранной профессии - это примерно как гордиться тем, что чего-то не знаешь. Бывают такие люди, но мне их жалко.
                            Ответить
                            • http://www.informit.com/articles/article.aspx?p=1941206
                              Ну я, к примеру, умею пользоваться отладчиком. В основном GDB (как правило, консольным интерфейсом). Но использую его я крайне редко, мне проще найти причину ошибки без него (например, тестами и вшитой в программу диагностикой, валидацией контрактов). В основном gdb полезен при разборе коредампа. В большинстве же встречающихся мне проблем отладчик просто бесполезен.
                              Ответить
                              • GDB известен феноменально "удобным" интерфейсом, "стабильностью" и "точностью". А код, который он дебажит известен феноменальным желанием сотрудничать с отладчиком, типа обширного RTTI, удобного способа представить объекты в виде строк, стек трейсами и т.д.
                                Если уж что-то брать в качестве примера, то лучше взять Яву + Идеию с ее интерфейсом.

                                Ах, да, еще забыл, GDB всегда однозначно и моментально находит нужный исходный код, который он сейчас рассматривает во время выполнения. И УГ макросы ему совсем не мешают это сделать.
                                Ответить
                                • ок, беру жабоотладчик и пошёл искать им тормоза и утечки ресурсов в плюсовых приложениях.
                                  Ответить
                                  • Ну а кто виноват, что язык херовый, не умеет помочь программисту? Отладчику тут как бы не много шансов оставили. Просто авторы языка все продумали до мельчайших деталей, убедились в том, что работать будет очень удобно, просто и понятно, а главное, что компьютер возьмет на себя выполнение механических и неинтересных задач, типа управления памятью. И сделали такой вот замечательный язык.
                                    Ну и вдобавок к замечательному языку уже ничего не оставалось кроме как написать замечательный отладчик - а что, ведь когда в языке вся информация уже есть, то отладчик написать - плевое дело.
                                    Ответить
                                    • Я к тому, что есть целые семейства проблем, которые принципиально не решаются отладчиком. Например, проблемы производительности, проблемы управления ресурсами, проблемы многопоточности (data races, deadlocks, live locks, starvation, тыщи их). Модель отладчика просто неспособна помочь в таких ситуациях. А убедиться в адекватной работе "бизнес-логики" я прекрасно могу и модульными тестами. Когда отладчик действительно необходим - так это post-mortem анализ.

                                      Жабий отладчик я тоже иногда использую, иногда в удалённом режиме, отлаживая какой-нибудь сервлет на удалённом сервере в два часа ночи. Но почти о всех случаях использования отладчика я жалел, т.к. просто посидеть и хорошенько подумать было бы более продуктивно, чем прогонять программу по шагам (жабоотладка в удалённом режиме, кстати, невероятно тормозит).
                                      Ответить
                                      • А еще отладчика за водкой не пошлешь - и нафига он нужен только?..
                                        Ответить
                                        • если попытаешь забить гвоздь отверткой - убидишся, что она очень плохой инструмент
                                          Ответить
                                          • > если попытаешь забить гвоздь отверткой - убидишся, что она очень плохой инструмент

                                            Ок. Раскрутим стек: множественные ретурны это плохо, ибо мешает могучим осиляторам дебаггера делать свою работу, ведь дебаггер это очень важно.
                                            Мне в моей работе дебаггер нафиг не нужен, ибо он не решает практически никаких проблем, с которыми мне приходится сталкиваться. Следовательно, "сложность работы с отладчиком" из-за множественных ретурнов - слабый аргумент для меня.
                                            Удобство чтения кода для меня гораздо важнее, чем удобство его отладки в дебаггере, ибо первым я занимаюсь гораздо больше, чем вторым.
                                            Ответить
                                            • > Мне в моей работе дебаггер нафиг не нужен, ибо он не решает практически никаких проблем,
                                              Потому что мне нравится закатывать солнце вручную! Специально поэтому я выбрал самый уебищный язык, в ктором любое действие, которое можно было бы автоматизировать, нужно делать вручную, в нем есть какие-то библиотеки, которые помогают это автоматизировать, но какой нормальный человек стал бы пользоваться этим языком? Поэтому библиотеки написаны такими же любителями закатывать солнце вручную.
                                              Теперь, у меня в работе есть много проблем: как разогнать тучи руками, как посторить космический корабль из подручных инструментов, как обучить оленей передвигаться в условиях невесомости так, чтобы они при этом могли за собой еще и космический корабль потянуть.
                                              И не важно, что можно было просто задернуть занавески - я ведь не за легкими путями шел сюда.
                                              Ответить
                                              • > закатывать солнце вручную
                                                Лол, использование отладчика - вот где закат солнца вручную. Сессии дебаггера невозможно воспроизвести без участия человека, они не приносят никакой пользы проекту, ничего не документируют; они выбрасываются и забываются сразу после своего завершения. Модульные тесты не страдают от этих недостатков.

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

                                                Действительно серьёзный софт сейчас пишется на C/C++/Java (В Google и Yandex, к примеру, c++ - основной язык). Все операционные системы написаны на этих языках, все базовые инструменты, даже небо, даже емакс. Если хочется писать что-то приличное, приходится использовать доступные инструменты. Да и не так уж они и плохи, как некоторые думают. Жить можно.

                                                Выпады по поводу автоматизации мне, простите, уж совсем непонятны.
                                                Ответить
                                                • Лол, написал человек, который управляет ресурсами вручную.
                                                  Да-да, расскажите еще про то, как сессии отладчика не воспроизводятся. Даже GDB имеет специально задокументированую возможность загрузить в него список команд, а жабий отладчик - так вообще может прям жабий код интерпретировать из файла.
                                                  Серьезный софт бла-бла-бла: миллиарды навозных мух не могут ошибаться. Серьезный софт это типа вебсайты верстать, или кнопки на формы расставлять? Или может быть все-таки серьезный софт, это исследовательские / научные / экспериментальные работы, где Ц++ и его брат-инвалид нахер не уперлись?
                                                  Ответить
                                                  • научные/исследовательские/экспериментальные работы - уже из названия следует разовость такого софта
                                                    обычно такой софт даже пишется непрофессионалами программирования - а физиками, биологами, етц
                                                    им надо построить модель, и им обычно насрать на производительность - конечно тут ц++ не упрется, его изучать надо столько же, сколько предметную область

                                                    серьезный софт - это тот, который без отладчиков в продакшене способен работать 24/7/365 в миллионных тиражах
                                                    Ответить
                                                    • Обычно исследовательский софт, который исследует проблемы программирования пишется непрофессионалами физиками и биологами /0.
                                                      По такому определению серьезности софта секретарши, которые лабалют ВБА макросы для форматирования дат в Иксэле - самые серьезные программистки. Куда там профессуре с кафедры информатики.
                                                      Ответить
                                                    • > серьезный софт - это тот, который без отладчиков в продакшене способен работать 24/7/365 в миллионных тиражах

                                                      +100500
                                                      Ответить
                                                  • > Лол, написал человек, который управляет ресурсами вручную.

                                                    ТЕЛЛ МИ МОАР АБАУТ РЕСУРС МЕНЕДЖМЕНТ ИН ЛИШП
                                                    А вы не управляете ресурсами вручную? Быть может, ваш язык имеет пакет telephaty и сам понимает, когда нужно закрывать файлы, сокеты, пайпы, когда нужно освобождать замапленные файлы, лочить/анлочить мутексы? loan pattern с коллбэком это, конечно, хорошо, только вот плюсовый RAII далает тоже самое без увеличения вложенности кода и накладных расходов на вызов функций. Да и не всегда удобна автоматизация в стиле loan pattern, поэтому в последнем крестовом стандарте внедрили rvalue-references и move-семантику. Память в куче - лишь капля в море ресурсов.

                                                    > Серьезный софт это типа вебсайты верстать, или кнопки на формы расставлять?
                                                    Ну я такими вещами вообще мало когда занимался, в основном ради собственного удовольствия. Серьёзный софт - это тот, который делает жизнь многих людей лучше, проще. Такой как мгновенный поиск данных в сети, общение, построение маршрутов. Или такой, реализация которого требует решения сложных инженерных задач.

                                                    > так вообще может прям жабий код интерпретировать из файла
                                                    чем это лучше модульного теста?
                                                    Ответить
                                                    • А что я говорил про тесты? Я не против тестов. Но отладчик - быстрее запускается, нагляднее, быстрее реагирует на изменившиеся обстоятельства, позволяет оперативно разрулить проблему вызваную ошибками / человеческим фактором.

                                                      Рассказать про with-open-file? Гугл в помощь.

                                                      Серьезный софт - это такой, который решает сложные новые задачи. Воспроизведение готовых решений - не серьезный софт, это ширпотреб.
                                                      Ответить
                                                      • > with-open-file
                                                        with-open-file и всего лишь экземпляр общей идеи, имя которой loan pattern. В Lisp он обычно реализуется макросом, что устраняет вызов функции в рантайме, но сути это не меняет.

                                                        > сложные новые задачи
                                                        Человеческие задачи не особо поменялись за тысячи лет, меняется лишь масштаб, качество и удобство решений.
                                                        Ответить
                                                        • > Человеческие задачи бла-бла
                                                          Сферическая тафталогия в вакууме. Просто бессмысленное предложение о смысле бытия и тщете всего сущего. С таким образом мысли лучше в общество Рериха вступать, а не програмы писать.

                                                          > экземпляр общей идеи
                                                          А вот тут как раз честно, ничего нового не придумали, просто авторы Ц++ не осилили даже это. Им же побыстрее холопов запрячь нужно, больше текста писать, чтобы было чем руки занять. Иначе ж работа встанет! Холопы начнут книжки читать, а там гляди и мысли отступнические появятся.
                                                          Ответить
                                                      • wvxvw, а ширпотреб не может быть серьезным?
                                                        Ответить
                                                        • На столько же на сколько школьный реферат может оказаться научным исследованием.
                                                          Ответить
                                                          • Нет, я имею в виду, разве широкое применение автоматически снижает качество решения?
                                                            Ответить
                                                            • Ширпотреб не потому, сколько людей пользуются, а потому, что копия. Т.е. на примере одежды: дизайнер придумал новую фуфайку, а на следующий сезон сто других дизайнеров скопировали выкройку фуфайки и растриражировали. Может быть, что новые фуфайки получились даже немного лучшего качества, чем оригинальная, но они все равно копии, и дизайнеры, которые их намоделировали не делали ничего нового / интересного.
                                                              Ответить
                                                              • > они все равно копии, и дизайнеры, которые их намоделировали не делали ничего нового / интересного.

                                                                Т.е. если несколько человек придумали новый полезный протокол и реализовали сервер, выдерживающий нагрузку максимум в 10 пользователей и падающий через день, а группа инженеров разработала отказоустойчивую распределённую систему, способную одновременно обслуживать миллионы пользователей круглосуточно каждый день, то последние не сделали ничего нового и интересного?

                                                                Ещё Брукс писал, что работа инженера-программиста, решающего задачу, поставленную архитектором, не менее творческая, интересная и сложная, чем работа самого архитектора. Просто задачи у них разные.
                                                                Ответить
                                                                • Брукс ошибался. Ничего творческого в такой работе нет. Хз, есть люди которым вдруг почему-то обидно, что они делают что-то не творческое, вот и придумывают херню всякую.
                                                                  Ответить
                                                                  • > они делают что-то не творческое, вот и придумывают херню всякую.

                                                                    ok, отсортировать 1тб данных на одной машине с 8 гб озу - с этой задачей справиться любой дебил, ведь все эффективные алгоритмы сортировки уже придуманы, осталось только циферки в формулу подставить, ага.

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

                                                                        ваш типичный слив "да вы меня все неправильно поняли, читайте что я написал много раз, обезьяны"
                                                                        Ответить
                                                              • > скопировали выкройку фуфайки и растриражировали

                                                                В отличие от моды, в программировании есть огромная разница между скопировать и смасштабировать.
                                                                Ответить
                                                              • wvxvw, IT сегодня - это не искусство, это инженерная дисциплина. Пример с дизайнером не совсем релевантен.

                                                                То, что тебе хочется творческих задач, в общем-то понятно, но изобретение нового - это не всегда то, чем приходится заниматься инженеру.

                                                                А за лиспоблядство и быстрый обход массива пидары обычно не хотят платить.
                                                                Ответить
                                                                • >wvxvw, IT сегодня - это не искусство, это инженерная дисциплина

                                                                  не согласен. Программировать технически грамотно, качественно и красиво - это исскуство
                                                                  Ответить
                                                                  • > не согласен. Программировать технически грамотно, качественно и красиво - это исскуство

                                                                    Программирование отчасти искусство, но всё же мы решаем инженерные задачи. 50/50, как во многих инженерных ремёслах
                                                                    Ответить
                                                                  • Приоритет в инженерных дисциплинах - нормально работающее и поддерживаемое решение, а не сляпать что-то новое любой ценой. Если есть подходящее готовое, проверенное решение - как правило, его и нужно брать.
                                                                    Ответить
                                                        • @anonimb#, у wvxvw просто осложнение интеллектуального илитизма на почве зашквара лишпом.

                                                          Серьёзные программисты редко занимаются научными изысканиями, им просто некогда. А если и занимаются, то самый важный их софт не так уж и важен с научной точки зрения. У Столлмана, к примеру, есть научные работы в области computer science, написанные в MIT, но самый важный его вклад - написание ширпотребного компилятора Си, ширпотребного дебаггера Си и объединение ширпотребных макросов для ширпотребного редактора TECO в ширпотребный Emacs. Учёным же редко когда есть дело до красоты программ и парадигм программирования. Я полтора года тусовался в ИПФ РАН, 98% научных работников успешно пишут нужный им софт на FORTRAN 77.
                                                          Ответить
                                                          • > Серьёзные программисты редко занимаются научными изысканиями, им просто некогда.
                                                            Некогда думать! Кодить надо! Проставь типы всем функциям и переменным, типы сами не проставятся!

                                                            А вообще, у вас просто непонимание русского языка и постоянная подмена понятий. Может ли быть что-то важное и не творческое? - Например дома посуду помыть? Может ли быть что-то не важное и творческое? - Да, известный пример с человеком который научился бросать чечевицу сквозь маленькое отверстие (случай с Александром Македонским).
                                                            Ответить
                                                            • > Некогда думать! Кодить надо!
                                                              Думать это очень хорошо, но кодить тоже, к сожалению, приходится. Причём довольно много, независимо от языка. Ололо в лиспе надо писать меньше букв - миф.http://www.jwz.org/doc/worse-is-better.html

                                                              > Проставь типы всем функциям и переменным
                                                              Ну всем, конечно, перебор, но ничего плохого в проставлении типов нет.

                                                              > у вас просто непонимание русского языка
                                                              куда уж быдлу понять ваш полёт мысли
                                                              Ответить
                                                              • Быдло не мои мысли не понимает, оно в своих путается.
                                                                Ответить
                  • >Для отладки все равно всегда приходится переписывать так, чтобы функция возвращала в самом конце

                    А не проще ли тестировать подфункции? Или составлять хорошие тесты?
                    Ответить
                    • Если код изначально херовый, то и тесты будут такими же, инфа 100%.
                      Ответить
                      • А если код изначально не херовый, то и отладчик не нужен, инфа 100%.
                        Ответить
                        • Увы, нет. Отладчик нужен всегда, тот кто думает не так - не умеет им пользоваться.
                          Ответить
                          • Нужность отладчика это тема для отдельного холивара ;)

                            Ок, давайте уточним терминологию. Что вы понимаете под отладчиком и под отладкой?

                            Классический пошаговый отладчик, или же REPL, в котором можно поиграться с функциями, и позапускать их в различных ситуациях?
                            Ответить
                            • Отладчик это программа которая будучи запущеной параллельно с тестируемой программой предоставляет информацию о внутреннем устройстве программы. В REPL по стандарту обязан быть отладчик, но это интерактивная разновидность. Большинство современных языков используют интерактивные отладчики, но это не обязательно. Отладчик может быть, например, запрограммирован наперед, чтобы просматривать какие-то определенные ситуации в программе, и делать это автономно. Например тот же хотспот компилятор пользуется отладчиком для того чтобы делать выводы о том, что нужно оптимизировать в первую очередь.
                              Ответить
                      • Если для тестов необходимо менять функции - тогда код херовый
                        Ответить
                  • Ок, раз прошлый пример я выбрал неудачно, достану из рукава еще один:
                    Object getPreset(String key, Object defaultValue) {
                        for (Map<String, Object> presets : presetsStack) {
                            Object result = presets.get(key);
                            if (result != null)
                                return result;
                        }
                        return defaultValue;
                    }
                    Как бы вы, с точки зрения стиля с одним возвратом, переписали этот код?
                    Ответить
                    • Блин, да что такое, этот пример тоже неудачен, т.к. легко переписывается с одним возвратом:
                      Object getPreset(String key, Object defaultValue) {
                          Object result = null;
                          for (Map<String, Object> presets : presetsStack) {
                              result = presets.get(key);
                              if (result != null)
                                  break;
                          }
                          return result != null ? result : defaultValue;
                      }
                      Ответить
                      • этот спор бессмысленен. Можно делать и так и так и не один из вариантов не лучше. Главное, что бы код был удобным и красивым и не стоит упираться в шаблон "100% нужно!" и "100% не нужно!". Лично я проще воспринимаю несколько выходов из функции.
                        Ответить
                        • > Можно делать и так и так и не один из вариантов не лучше. Главное, что бы код был удобным и красивым и не стоит упираться в шаблон "100% нужно!" и "100% не нужно!".
                          Ну я эту мысль и пытаюсь выразить на протяжении этого треда... Но для этого мне нужно опровергнуть тезис о том, что одного возврата всегда достаточно.

                          > Лично я проще воспринимаю несколько выходов из функции.
                          Аналогично.
                          Ответить
                          • >Но для этого мне нужно опровергнуть тезис о том, что одного возврата всегда достаточно.

                            А одного - всегда достаточно) Любую функцию с множеством выходов можно свести к функции с одним. Хотя бы применяя систему условий и флагов. Это исключительно дело вкуса
                            Ответить
                      • Да возьми просто пример отсюда http://govnokod.ru/13703#comment193704 - или плоский код с множеством ретернов, или лесенкой, но с одним.
                        Ответить
                    • (or (some #'identity preset-stack) default-value)

                      В чем смысл выбирать самые уебищные языки, а потом жаловаться на то, как в них все плохо и нельзя сделать хорошо?
                      Попробуйте еще на XSLT что-нибудь такое слабать, а потом удивляться, почему так плохо. Тот кто язык придумал вложил просто очень много ума и усилий в то, чтобы сделать программирование удобным, поэтому хомячки теперь наслаждаются и изобретают заплатки поверху своих мегаудобных инструментов.
                      Ответить
                      • Ну код не совсем эквивалентен, вместо identity надо поставить поиск в мапе. Но решение очень красивое. Вот такой код и надо показывать для привлечения интереса к лиспу :)
                        Ответить
            • > либо хранить состояние ошибки в переменной и проверять ее при дальнейших действиях
              возвращаемся к ассемблерным флагам?
              это только представьте, какой спагетти-код будет. и, в отличие от спагетти, не столь легкоусвояемый.

              пы.сы. пойду пожру.
              Ответить
              • напиши когда в туалет пойдешь - нам очень интересно
                Ответить
                • gps показал, что я в туалете со скоростью 50 км\ч
                  Ответить
                  • gps в помещениях вообще любит показывать, что его хозяин занимается паркуром, бегая с большой скоростью в радиусе 100-200 метров вокруг своего дома.
                    Ответить
                    • фраза "снять штаны и бегать" неожиданно начинает иметь обретает смысл
                      Ответить
          • Зачем тут исключения? Пых может функцию по имени вызвать, просто сложить их всех в массив и вызывать пока не сломается. Типа:
            while (call_user_func($validators[$i])) { $error = $errors[$i++]; }
            Ответить
            • Ну вот остается немного доработать напильником, чтобы можно было не только указывать имя валидатора, но и передавать ему немного параметров, и получится декларативная валидация форм ;)

              Жаль в пыхе массивы некрасиво описываются.
              Ответить
        • Ох блин. И ко всему этому - сброс формы после каждой отправке. Типа "Епитесь, дорогие пользователи".
          Ответить
      • Кстати, вот у меня в VS компилируется код максимум с 123 вложенными if'ами), иначе пишет: "fatal error C1061: compiler limit : blocks nested too deeply".
        Ответить
        • мне кажется, это epic fail. ну, что ж, удачного рефакторинга =)
          Ответить
        • Это давно известный факт. В принципе, особого криминала нет - компилятору вертеть в памяти глубокими AST невыгодно, а такой глубины на практике более чем достаточно. Единственная проблема - наличие глупых кодогенераторов. Но писать кодогенератор, производящий сотни вложенных ифов, как-то неразумно, таблицы же рулят.
          Ответить
          • Кстати, крестостандарт рекомендует 256, но там написано, что реализация вольна выбрать любой другой разумный лимит.

            В гцц не помню, но вроде 256 и есть. Ненамного больше для генератора, совсем не отличимо от 128 для кода, который пишут руками.
            Ответить
            • я стараюсь всячески избегать глубины более чем 3 вложений. бэк практис, гуд практис, меня это честно говоря как-то мало волнует. я просто знаю, что бизнес-логика может поменяться в любой момент, и тратить кучу временя на разбор этого фарша я не собираюсь =) мне и так достался проект, где один метод примерно на 1000 строк с if... elseif.... elseif... elseif... elseif
              да и в каждом таком еще по 3-4 вложенных elseif.
              Ответить
              • > тратить кучу временя на разбор этого фарша я не собираюсь
                Так я о чем и пишу... Человеку насрать на эти ограничения с высокой колокольни. Ему что 256, что 128, что всего лишь 8. Разницы он не заметит.
                Ответить
              • самый здоровый подход к теме. главное - удобство рефакторинга и читабельность кода
                Ответить
        • там еще и адовые ограничения на количество типов в шаблоне
          те ещё суки!
          Ответить
    • стрелочка....
      еда - туда >
      Ответить
    • и да, в строке №19 единственная точка выхода.
      Ответить
      • Одновозвратники не одобрят, ибо есть еще одна в 32й.
        Ответить
        • это точка возврата.
          Ответить
          • Но где же тогда точка извлечения и точка выброса?
            Ответить
          • Гораздо страшнее точка невозврата.
            Ответить
            • кстати. недавно с коллегой случилась история: подзывает меня, говорит: посмотри ты, а то я не понимаю, что происходит.
              а происходит следующее: в дебаггере шагает, заходит в try блок, выходит, не заходя в finally, и пропадает бесследно. у него в этот момент пошатнулись каноны мира, он чуть в магию не поверил.
              оказалось проще: там внутри создавался сокет, который вечно слушал... программа просто зависала )
              Ответить
              • Встречалась мне пара аномальных случаев.

                Один раз там потом похожая херня оказалась - http коннект без таймаута ждал 2 дня, потом отваливался.

                А второй раз был гейзенбаг и вроде как finally дейстивтельно не отрабатывало, но это было давно, под 1.4 . Тогда так и осталось неясным, то ли сервер душил каким-то хером тред, то баг в JIT.
                Ответить
            • Исключение: Функция выпала за горизонт событий
              Ответить
    • паттерн "Клин"
      Ответить
    • Эх.. А где была картинка из этого кода и человечка, бросающего в него огненный шар, который как бы сдвигает код по форме отступов?
      Ответить
      • А, всё. Нашёл. Кинул строчку кода в гуглокартинки :)
        http://i.imgur.com/BtjZedW.jpg
        Ответить
    • показать все, что скрытоAlergyx – это уникальная, безопасная и эффективная комбинация растительных экстрактов, которая, будучи принятой внутрь, уже в течение 10 минут блокирует реакцию организма на аллерген, останавливая или предотвращая проявление аллергии. Полный курсовой прием препарата в течение 30 дней полностью избавляет от хронических форм недуга, очищает от токсинов и восстанавливает организм.
      ALERGYX помогает нашему телу выработать собственные «блокирующие антитела», которые НАВСЕГДА ИСКЛЮЧАТ ВОЗМОЖНОСТЬ ПОВТОРНОГО ВОЗНИКНОВЕНИЯ АЛЛЕРГИИ.
      Официальный сайт: http://alergyx.bxox.info
      Ответить

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