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

    +178

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    if($active_days > 4)
    {
    	$active_days = 1;
    }
    else
    {
    	if($active_days > 5)
    	{
    		$active_days = 1;
    	}
    }

    В цикле

    Запостил: vizio, 21 Февраля 2011

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

    • забавная конструкция))

      все таки понимание основ программирования бывает крайне полезно даже в таких, казалось бы не связанных с программированием вещах, как веб-разработка на пхп
      Ответить
    • А отступы чьи? Ваши или горе-кодера?
      Ответить
      • Неважно, отступы и автомат поставить сможет.
        Ответить
        • Да, тут скорее всего автоформатирование ИДЕ, ибо все гладко.
          Ответить
        • да и автор этого кода тоже не факт что пройдет тест тьюринга
          Ответить
      • мне одному кажется, что с отступами все в порядке?
        Ответить
        • Вот именно что все в порядке. У такого говна не должно такого быть.
          Но тут скорее всего работа IDE
          Ответить
          • а это плохо? я вот эклипс настроил себе так, что он при сохранении форматирует код и добавляет немного избыточной ясности (this., @Override, final и проч.)
            Ответить
            • final-то зачем?
              Ответить
              • я сначала тоже думал, что не нужно. А потом оказалось очень полезно: помогает повторно использовать обьекты
                Ответить
                • В смысле использования немутабельных объектов? Ну так такие классы специально проектировать надо (и финализация всех полей -- необязательное условие). А где-попало сорить final не нужно -- неожиданно окажется, что метод нужно переопределить в наследнике, а переменной присвоить значение. В результате diff будет больше.
                  Ответить
                  • нет, не иммутабельных, а что бы ссылка оставалась прежней, и лишний раз new не дергать. Во-первых, это ощутимо сказывается на быстродействии в циклах, а во-вторых, зависимости "автоматически" держатся в актуальном состоянии.
                    Например, у меня в играх есть обьект "поле", и есть компонент, которое это поле рисует - ему я скармливаю ссылку на обьект поле.(это не плохо, надеюсь?) При загрузке нового уровня можно:
                    1. уничтожить старое поле, создать новое и присвоить новое компоненту
                    2. обновить поле спец.методом, компонент сам нарисует
                    Я предпочитаю 2ой способ, вот здесь final страхует от искушения переопределить поле (IDE сигналит ошибкой компиляции). Тогда решаем, или искать способ обновлять поле (добавить соотв. метод), или убирать final


                    Далее, насчет методов. Я выработал такую привычку: при проектировании класса сразу решать, а разумно ли давать расширять этот класс. Если нет, то ставим final классу. Если да, то решаем каждому методу, может ли понадобиться его переопределить(что бы не было НЕОЖИДАННО). Если да, то зачастую этот метод будет или protected, или abstract protected. Если нет, делаем ему final.
                    Если же вдруг оказалось, что нужно переопределить final метод, то думаем еще раз, а ДЕЙСТВИТЕЛЬНО ли это нужно (лажанулся ли при проектировании) - может быть, финализировал его таки не зря, и нужно думать другой подход.
                    Ну а если лажанулся, то и это не страшно - в свн'е будет лишняя неконфликтная строчка. Но в моей практике это редкий случай - точнее, я даже сейчас не помню ни одного такого случая.
                    Ответить
    • Да, надо было показать знание учебника, объединить в elseif, так бы симпатичнее вышло.
      Ответить
      • Не надо было. Надо было просто так:
        if($active_days > 4)
        	$active_days = 1;


        Смотрите - если у нас $active_days не > 4, то > 5 он быть ну никак не может, следовательно, вторая проверка на > 5 бессмысленна.
        Ответить

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