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

    +161

    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
    $id_country = 0;
    $id_region = 0;
    $id_city = 0;
    $zip_code = 0;
    if(isset($_REQUEST["id_country"]))
    {
        $id_country=$_REQUEST["id_country"];
    }
    if(isset($_REQUEST["id_region"]))
    {
        $id_region=$_REQUEST["id_region"];
    }
    if(isset($_REQUEST["id_city"]))
    {
        $id_city=$_REQUEST["id_city"];
    }
    if(isset($_REQUEST["zip_code"]))//проверка zip кода
    {
        $zip_code=$_REQUEST["zip_code"];
    }
    
    $id_country=strip_tags(trim(strval($_REQUEST["id_country"])));
    $id_region=strip_tags(trim(strval($_REQUEST["id_region"])));
    $id_city=strip_tags(trim(strval($_REQUEST["id_city"])));
    $zip_code=strip_tags(trim(strval($_REQUEST["zip_code"])));
    
    ..........................
    //переходим на Шаг 2 решистрации
    header("location: ./registration.php?sel=2");
    ..........................

    Индусы среди нас!

    Запостил: Bartelby, 25 Августа 2009

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

    • Великолепный пример!
      Сначала нагородить огород, а потом вовсе его не использовать. Его можно в учебники вносить. :)
      Ответить
    • Да, забыл написать, что это кусок кода из файла registration.php
      Ответить
    • o_O, судя по комментам - не индусы. Интересно, а если филдов в запросе не 3 а 30?
      Ответить
      • "Индус" - это уже собирательный образ, нарицательное, означающее программиста, который работает быстро, но плохо.
        А количество полей большое всегда плохо. Априори каждое поле уникально и требует индивидуального подхода. Правда код в данной интерпретации мог быть и укорочен каким-нибудь циклом. Однако, я склонен полагать, что здесь вновь действует один из приёмов "парадигмы быстрого программирования" - создать кусок кода "на потом", авось пригодится, авось для каждого поля придётся применять свою стратегию.
        Ответить
        • Если кастомовая обработка полей даже теоретически может потребоваться, то ИМХО сразу следует создать класс-обработчик формы (или воспользоваться чем-то типа Zend_Form). Времени на это тратится (при наличии мозгов, естественно) минимум - а гибкость и масштабтруемость сразу повышается в разы. А после таких применителей RAD потом проще переписать код полностью, чем разбираться - что именно они курили.
          Ответить
          • Я к сожалению не знаком с Zend_Form, но не вооружённым глазом видно, что это монстр, который будет реализовывать сотни контрактов из которых нужны пять. Стрельба из пушки по комарам получится. То есть, вся проверка полей будет состоять из того, что должен быть выполнен контракт хранения данных (правильность типа) и контракт связи. Контракт связи полностью зависит от сайта. Таким образом применение стороннего монстра становится просто неоправданным. Создание же своего класса-менеджера, главного класса вполне реально. Он сможет стразу осуществить контракты типа и контракты связи, использую заданный набор стратегий, применяемых к полям формы. С другой стороны создать хороший класс менеджер из небольшого числа стратегий будет в PHP затруднительно вследствие ограниченности ООПа.
            Ответить
            • че? о_О
              Ответить
              • Это я для stan написал, он, по-моему, не из PHP.
                Тут в чём вопрос. Предположим нужно обработать поле "номер телефона". Я предполагаю "правильные" номера: xxxxxxx, xxx xx xx, xxx-xx-xx, где x - цифра. Но внутри храню всегда xxxxxxx, где x - цифра. Тот факт, что номер должен из формы в переменную попасть одним из трёх видов - это условие правильной работы скрипта, он не сможет понять номер, если он будет xx-x-x-x-xx, а x - буква. Это предусловие. Соответственно, класс-менеджер должен иметь для этого случая метод (функцию-член) ValidatePhoneNumber($phoneNumber) - этот метод есть контракт входящего типа. Я принимаю только номера определённого типа и для проверки вызывают определённый метод, которым должен обладать класс-менеджер. Но кроме того я храню номер в виде числа. И будет существовать метод, который принимает уже не произвольную строку, а определённого вида и сохраняет её числом SavePhoneNumber($validPhoneNumber) - это моё дело (а вот номера, скорее всего, в одном и том же формате все будут принимать, и я, и вы), как работает эта функция-член. Но она тоже должна быть, я её использую, она входит в контракт.
                Поля, скорее всего, часто будут иметь что-то очень схожее и я смогу написать несколько стратегий: стратегии сохранения, стратегии проверки. После чего проверю какие у меня встречаются поля в данной форме и сформирую класс, реализующий определённые стратегии, из них состоит полный набор методов класса, эти методы будут разбиты на пары, для каждого поля (или нескольких похожих), эти пары и есть контракты с полями.
                Ну как-то так...
                Ответить
                • 2 interested: не совсем из php, хотя и из него тоже.
                  Вообще говоря я имел ввиду что-то подобное. О глубине реализации можно рассуждать в зависимости от проекта. Я бы для валидации/сохранения различных типов полей использовал различные стратигии, наследуемые от базовой, реализующие некий интерфейс и т.п.
                  p.s.>говнокод потихоньку превращается в общение на тему "а как бы сделал я"
                  Ответить
                  • >>превращается в общение на тему "а как бы сделал я"
                    Я тут newbie. Не знаю ещё, что принято.

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

                    >>различные стратигии, наследуемые от базовой, реализующие некий интерфейс

                    ...то возникнет вариант, который можно использовать удобно В РАЗНЫХ проектах. Да, на одном сайте не выиграем, зато насколько быстро сможем создавать новые классы для обработки форм в будущем. Соединим различные стратегии в одном контракте и получим новый класс-обработчик. Для другого сайта другой. Но при этом быстро и интерфейс будет равен контракту, а ничего нового мы и не писали, просто комбинировали написанное.
                    Отыскивать куски для копирования на новый сайт из кода вида данного #1679 "говнокода" будет в разы сложнее. Тогда и будет удобнее написать сайт заново. И тут вопрос скорости кодирования "индуса". Он может настолько быстро кодировать, что даже заново будет быстрее, чем у других с повторным использованием. Потому нужно и продуманное решение и быстрое. Именно это и порождает "индусов".
                    Если есть хорошая команда, которая может создать хорошее ПО, зачем заставлять её кодить? Пусть они напишут хороший core, а на него мы будем навешивать что-то быстро. Пригласим тех, кто пишет код быстро, не важно как... Потом будут заплатки... Это позволяет быстрее выйти на рынок. Скорость разработки для интернета ещё требовательнее, потому "плохого" кода на популярном языке будет много, потому что нужна скорость выхода на рынок.
                    Ответить
                    • Да, к сожалению подход "лучше день потерять, потом за пять минут долететь" очень редко в почете у заказчиков. В результате возникает отжиг типа выше приведенного (а также говнокода #1671, который обнаружился в одном очень даже живом и успешном буржуйском магазинчике). Соответственно на саппорт такого кода тратится очень несмешное время. Особенно если проект достался по наследству от "индуса", а самого индуса уже давно и след простыл.
                      Ответить
              • Ещё хороший пример mysqli.
                Там очень много методов, они составляют полный интерфейс класса. Но, положим, я или вы используем только десять из них. Эти десять методов - наш контракт с классом mysqli. Он мог бы ничего не делать, кроме этих десяти методов, а сценарий работал бы. Но если он не реализует в интерфейсе хотя бы один метод из контракта, то сценарий не работает, даже есть mysqli будет ещё тысячу методов иметь.
                Соответственно, если вы используете класс с большим интерфейсом при небольшом контракте - вы используете класс неэффективно.
                С другой стороны вы могли бы, скажем, брать данные из базы и записывать в файлы. Вам нужен контракт из методов и того, и другого. Тогда вы можете создать новый класс, который соберёт часть методов из класса ресурса баз данных и часть методов из класса работы с файлами. Получится новый класс, который делает то, что нужно.
                Ответить
    • А только что выяснилось, что 3 из 4-х полей - численные индексы...
      мну плачет...
      Ответить
      • а по приставке id_ никак нельзя было об этом догадаться?:)
        Ответить
        • ммм да
          $id_city=strip_tags(trim(strval($_REQUES T["id_city"])));
          выглядит короче чем
          $id_city = (int)$_REQUEST['id_city'];
          8))
          Ответить
          • а если в $_REQUEST нет такого элемента как 'id_city'? =)
            Ответить
            • А на случай, если нету, $cityId = isset($_REQUEST['id_city'])?(int) $_REQUEST['id_city']:0;
              Ответить
        • А вы не встречались с текстовыми ID? например 2-х буквенные ID языка или коды штатов США (тоже двухбуквенные)...
          Ответить

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