1. JavaScript / Говнокод #11778

    +156

    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
    @show[]
    $cars[^table::sql{select * from count_cars order by sortir}]
    <script>
    var CarsDescription = new Array()^;
    $counter(1)
    ^cars.menu{
    CarsDescription[$counter] = '$cars.characteristic'^;
     ^counter.inc[]
    }
    </script> 
    <script type="text/javascript" src="/cars_calc/script.js"></script>
    <link rel="stylesheet" type="text/css" href="/cars_calc/style.css">
    <section class="page">
       <section class="scheme">
        <span id="cr" class="cr"></span>
            $cars_count(16)      
            ^for[car](1;$cars_count){ 
        <span id="select-car-$carId" class="car-$carId">$car</span>
            }
     </section>

    Код из одной веб-студии. Смысл в том что в javascript должен быть передан массив из базы данных, вместо того чтобы послать пакет с нужными данными в формате json (или любом другом) и обработать его, в исходный файл html-разметки (тут как видно и javascript вставлен) добавили код Parser'а (для тех кто-незнаком это язык для быстрой разработки веб-сайтов от Лебедева, что-то вроде простой альтернативы php), который перед тем как отдать пользователю страницу, обрабатывает её и вставляет в нужные места, нужные данные. В общем сами оценивайте этот маразм...

    Запостил: Kerny, 16 Сентября 2012

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

    • у меня такое впечатление, будто obj-c скрестили с js
      Ответить
    • >от Лебедева
      Артемия?
      Ответить
      • > Артемия?
        Его самого.

        P.S. Не люблю этот высерпарсер. Доводилось разбираться со страничкой на нем один раз, в течении всего процесса хотелось кого-нибудь убить.
        Ответить
        • уж лучше котеров
          Ответить
        • Было дело, работал в канторке, которая отпочковалась от артемия очень давно. И парсер этот прихватила с собой. Так вот все ранние сайты этой канторки сделаны на парсере. И как-то получил я команду слить исходники сайта клиенту, который долгое время хостился на корпоративном серваке, и вот, посравшись с канторкой, решил свалить на свои сухари. А сайт то весь на парсере... Мне стало горько - клиент оху**т этот сайт выкладывать на свой хостинг, это же еще и интерпретатор надо ставить со всеми вытекающими. Кароче не знаю как они там разобрались...
          Ответить
          • Мне кажется, для того и сделан этот парсер, чтобы уходить было сложнее. Другой причины не вижу.
            Ответить
            • уйти и запилить свой php, ну вы поняли.
              Ответить
              • Хотя, к чёрту php... и блекджек... а, к чёрту всё.
                Ответить
              • > запилить свой php
                PHP done right?

                "The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right."
                (c) Linus Trollvalds

                Перефразировав маэстро, скажу: "There is no way to do PHP right."
                Ответить
                • Дело не в том, что пышечку нельзя сделать сделать правильно, проблема в том, что если сделать пых правильно он превратится в яву. А зачем нужна еще одна ява ? (в крайнем случае в питон)
                  Ответить
              • лебедев стремится показать неординарность своего мышления
                Ответить
      • угу
        Ответить
    • select * from count_cars order by sortir

      Вот где говно притаилось.
      Ответить
      • выбор числа машин командуется уборными... так я и знал.
        Ответить
    • Хе-хе, я сам на заре веб-карьеры так делал: внедрял php скриптом json-массив при рендеринге странички в вызов функции. В который раз жалею, что исходники безвозвратно потеряны...
      Ответить
      • Знакомо
        Ответить
      • а что, так делать нельзя?
        Ответить
        • Можно, и оно работает, причём быстрее (не нужен дополнительный XHR слать, все данные под рукой). Просто код довольно дикий получается, саппортить сложно. Я тогда просто не мог в ajax.
          Ответить
          • а-а-а. ну да, код конечно страшноватый, но сейчас, мне кажется, исходный код никто не смотрит - глядят firebug'ом и подобными тулзами
            Ответить
            • Я имею в виду код, которые генерит js-код. Языки перемешаны, генерация javascript внутри кода страницы конкатенацией строк чревата ошибками и плохо поддерживается.
              Ответить
              • тоже верно. хотя у нас в проектах не особо страшно выходит (rails/haml).

                :javascript
                var data = #{@data};
                Ответить
                • все равно, как ваш код суппортить не знакомому программисту? Что с отладкой?
                  Ответить
          • по моему работает в совокупности медленнее, это каждый раз когда страничка отдается юзеру, она должна проходить через шаблонизатор, каждый когда данные взяты из БД нужно открывать еще и этот html - файл и проходить по нему.
            Ответить
        • Категорически - нет! Такой подход подойдет только маленьким говно-проектам.
          Ответить
          • Большим говно-проектам он тоже подойдет. Они ведь все равно говно-проекты.
            Ответить
          • а можно поподробнее объяснить почему нет?
            Ответить
            • выше собственно уже все написали. Нарушается целая куча паттернов и парадигм при проектировании.
              Ответить
              • > каждый раз когда страничка отдается юзеру, она должна проходить через шаблонизатор
                зачем? она может быть закеширована на сервере.

                Тут скорее важно, какие данные будут вставлены в js. Встраивать часто меняющиеся данные нет смысла. А вот небольшие объемы редко меняющихся - считаю вполне оправдано.

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

                    резюмируя (и заканчивая) нашу дискуссию:
                    1. С фразой "Категорически - нет!" - не согласен; думаю, что вообще никогда не соглашусь с категорическим утверждением, т. к. почти всегда можно найти ситуацию, где корявейшее на первый взгляд решение может быть оправдано.
                    2. Применение указанного приема должно иметь хорошее обоснование. Не видишь, что плюсов и выгоды будет больше - не применяй.
                    Ответить
                    • > т. к. почти всегда можно найти ситуацию, где корявейшее на первый взгляд решение может быть оправдано.

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

                      Просто мне нравятся лаконичные решения. Т.е то что выше я считаю выходит далеко за рамки лаконичности.

                      Да обоснование нужно иметь. Раньше, когда я только знакомился с программированием, я считал, что должен любым образом оптимизировать (в плане быстродействия) свой код, как правило это очень запутывало его. Сейчас у меня совершенно иной подход, я стараюсь писать код понятный другому программисту, хотя мой код никто не читает (пишу я для себя по большей части).

                      Везде есть быстрые, без заморочек решения. Как панельные дома в СССР, которые строились "на время" без лишней головной боли, но в этих домах до сих пор живет куча людей. В общем я хочу сказать, что у нас в стране это основная проблема. Она в умах, а с этим трудно что-то поделать.
                      В общем спасибо за беседу.
                      Ответить

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