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

    +146

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    if($this->unpriced){
                //...............  строк 30 кода
                if($this->unpriced){
                      //................ строк 10 кода
                }                
    }

    Вот такую забавную проверку нашол в старом коде. Видать, для уверенности, или скорее всего логика менялась.

    Запостил: Edd, 12 Марта 2012

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

    • if($this->unpriced){
      // тут $this->unpriced может изменить значение
      if($this->unpriced){

      }
      }
      Ответить
      • Если бы значение менялось, не выкладывал бы :)
        Ответить
        • Но мы то этого не знаем, в любом случае менять значение внутри такой проверки - некрасиво
          Ответить
    • >нашол
      Ответить
    • Что еще раз подтверждает мысль о том, что функции размером больше экрана (80x25 символов) - зло
      Ответить
      • это глупая точка зрения
        Ответить
        • это базовый принцип процедурного программирования
          Ответить
          • базовый принцип процедурного программирования – это разбиение функциональности на небольшие части-процедуры готовые к повторному использованию и построение программы из этих частей. Нигде не говорится про эти долбоебские размеры в 80 на 25. Сложность функции от этого никак не зависит
            Ответить
            • Есть метрики, оценивающие сложность кода. Ограничение ширины в 80 символов - да, слишком строго (особенно с java naming'ом). А вот 25 строк - это очень часто слишком много для одной функции.
              Ответить
              • одна из ключевых фраз принципа – "готовые к повторному использованию". Нет смысла разбивать функцию только потому, что она занимает больше 25 строк, если потом эти части по отдельности не смогут работать. Это создает только иллюзию модульности и больше запутывает, т.к. кардинально идет вразрез с "бритвой Оккама".
                Кстати, я считаю самой адекватной метрику оценки по точкам принятия решения (она описывалась в Совершенном коде).
                Ответить
                • Есть смысл разбивать большие функции, даже если полученные небольшие простые функции больше нигде не используются, и вот почему: если ваша функция занимает много строк, с вероятностью 0.9 в ней смешаны несколько уровней абстракции (об это кажется упоминается в "Clean Code" Роберта Мартина). Произведя декомпозицию, можно сделать код значительно читабельнее.
                  Ответить
                  • думаю, стоит говорить "В некоторых случаях есть смысл разбивать ...". Я согласен, что чаще всего функция в 100 строк должна быть разбита, но я против именно жесткого следования такой практике, потому что можно попасть в те 10%, где абстракция не будет смешиваться, потому что можно разбить и выбрать неудачные имена, которые только будут запутывать.
                    Ответить
                    • Да, иногда хочется убить оппшных товарищей. Когда в мозг приходится загружать абстрации абстракций наследованные от десяти классов и аккуратненько разбитые на методы по 10 строк... Еще можно комменты оставлять на каждой строчке чтобы вообще шансов прочитать не было.
                      Ответить

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