"PHP" / Говнокод #9656 Ссылка на оригинал

0

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

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

Запостил: Edd Edd, (Updated )

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

  • ava rO_ot # Ссылка на оригинал 0

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

    }
    }
    Ответить

    • ava Edd # Ссылка на оригинал 0 ⇈

      Если бы значение менялось, не выкладывал бы 🙂
      Ответить

      • ava guest # Ссылка на оригинал 0 ⇈

        Но мы то этого не знаем, в любом случае менять значение внутри такой проверки - некрасиво
        Ответить

  • ava myaut # Ссылка на оригинал 0

    Что еще раз подтверждает мысль о том, что функции размером больше экрана (80x25 символов) - зло
    Ответить

      • ava guest # Ссылка на оригинал 0 ⇈

        это базовый принцип процедурного программирования
        Ответить

        • ava FAKYOUINTIRNEAT # Ссылка на оригинал 0 ⇈

          базовый принцип процедурного программирования – это разбиение функциональности на небольшие части-процедуры готовые к повторному использованию и построение программы из этих частей. Нигде не говорится про эти долбоебские размеры в 80 на 25. Сложность функции от этого никак не зависит
          Ответить

          • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

            Есть метрики, оценивающие сложность кода. Ограничение ширины в 80 символов - да, слишком строго (особенно с java naming'ом). А вот 25 строк - это очень часто слишком много для одной функции.
            Ответить

            • ava FAKYOUINTIRNEAT # Ссылка на оригинал 0 ⇈

              одна из ключевых фраз принципа – "готовые к повторному использованию". Нет смысла разбивать функцию только потому, что она занимает больше 25 строк, если потом эти части по отдельности не смогут работать. Это создает только иллюзию модульности и больше запутывает, т.к. кардинально идет вразрез с "бритвой Оккама".
              Кстати, я считаю самой адекватной метрику оценки по точкам принятия решения (она описывалась в Совершенном коде).
              Ответить

              • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                Есть смысл разбивать большие функции, даже если полученные небольшие простые функции больше нигде не используются, и вот почему: если ваша функция занимает много строк, с вероятностью 0.9 в ней смешаны несколько уровней абстракции (об это кажется упоминается в "Clean Code" Роберта Мартина). Произведя декомпозицию, можно сделать код значительно читабельнее.
                Ответить

                • ava FAKYOUINTIRNEAT # Ссылка на оригинал 0 ⇈

                  думаю, стоит говорить "В некоторых случаях есть смысл разбивать ...". Я согласен, что чаще всего функция в 100 строк должна быть разбита, но я против именно жесткого следования такой практике, потому что можно попасть в те 10%, где абстракция не будет смешиваться, потому что можно разбить и выбрать неудачные имена, которые только будут запутывать.
                  Ответить

                  • ava kyzi007 # Ссылка на оригинал 0 ⇈

                    Да, иногда хочется убить оппшных товарищей. Когда в мозг приходится загружать абстрации абстракций наследованные от десяти классов и аккуратненько разбитые на методы по 10 строк... Еще можно комменты оставлять на каждой строчке чтобы вообще шансов прочитать не было.
                    Ответить

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

Переведи на "PHP", guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓