На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (7) [1] 2 3 ...  6 7 все  ( Перейти к последнему сообщению )  
> Чистота кода VS оптимизация
    Много статей развелось про чистоту кода (на основе книги Р.Мартина и не только). В целом концепция, конечно, хорошая.
    Но бывают какие-то прямо абсурдные, ИМХО, рекомендации.
    Вот к примеру тут:
    ExpandedWrap disabled
      // ????
      const fetchData = (id) => {
        if (id) {
          fetch('/data/' + id)
        }
      }
      // ????
      const fetchData = (id) => {
        if (!id) {
          return
        }
        fetch('/data/' + id)
      }
    Ну что это за "красота" такая?

    И вот такие слова в конце статьи:
    Цитата
    «Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось.

    С таким мышлением закон Вирта совершенно не кажется "шуткой":
    Цитата
    Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее

    Далее, второй момент. Более "тонкий", скажем так.
    Example1 (кусочек кода):
    ExpandedWrap disabled
      . . .
        while i*i <= n:
          k = 1
          while n % i == 0:
            k += 2
            n //= i
          result /= k
          i += 1
      . . .

    Example2 (кусочек кода):
    ExpandedWrap disabled
      . . .
        while i*i <= n:
          if n % i == 0:
            k = 3
            while 1:
              n //= i
              if n % i: break
              k += 2
            result /= k
          i += 1
      . . .
    Не углубляйтесь в суть алгоритма, это неважно.
    Второй вариант чуть более сложный для понимания (спасибо разработчикам Python'а за отсутствие do-while/repeat-until), но и чуть более оптимальный по скорости, ибо тут нет лишнего деления (ну и кое-чего ещё по мелочи).
    Согласен, не самый показательный пример (особенно учитывая, что это скриптовый язык, но давайте не будем обращать на это внимания, вникните в суть темы... представьте, что это C++ :)).

    Собственно, можно особо не заморачиваться и использовать первый вариант. Но представим, что мы пишем библиотеку и не знаем как она будет использоваться. Насколько критична будет скорость в финальном коде?

    Ваши мысли обо всём этом безобразии... :whistle:
      Не читай плохих статей! :lol: Создавать Elephantware имеет смысл только тогда, когда ты в пожизненной разработке проекта, и тебе оплачивают не качество, а количество доработок.
        Цитата Jin X @
        Не углубляйтесь в суть алгоритма, это неважно.

        как это не углубляйтесь? возможно там вообще деление не нужно
          Цитата villain @
          как это не углубляйтесь? возможно там вообще деление не нужно
          Суть вообще не в этом. Будем считать, что алгоритм достаточно оптимален (это часть кода разложения на простые множители и манипуляции с ними), но есть 2 вот таких варианта реализации :)
          Там вообще умножение должно быть, я заменил его на деление для пущего эффекта :D
            Цитата JoeUser @
            Создавать Elephantware имеет смысл только тогда, когда ты в пожизненной разработке проекта, и тебе оплачивают не качество, а количество доработок.
            Не, ну понятно, что создавать класс в 3 поколения с 10 методами в каждом там, когда нужно сделать просто min(x,y) - это бред. Речь идёт именно о чистоте кода, а не о заделе на будущее. Т.е. о понятности кода тебе и людям с возможностью лёгкой модификации.
            Реально ли (почти) всегда нужно писать одно действие-одна функция и выстраивать 5-этажные вызовы там, где можно было бы обойтись одной функцией?
            Реально ли (почти) всегда стоит заменять:
            ExpandedWrap disabled
              // ????
              people
                .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4)
            на:
            ExpandedWrap disabled
              // ????
              people
                .filter(person => person.age > 10)
                .filter(person => person.firstName.length > 2)
                .filter(person => person.lastName.length > 4)
            ради лучшей читабельности? И т.д.
              Цитата Jin X @
              Реально ли (почти) всегда стоит заменять:
              ExpandedWrap disabled
                // ????
                people
                  .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4)
              на:
              ExpandedWrap disabled
                // ????
                people
                  .filter(person => person.age > 10)
                  .filter(person => person.firstName.length > 2)
                  .filter(person => person.lastName.length > 4)
              ради лучшей читабельности? И т.д.

              Можно еще вот так
              ExpandedWrap disabled
                // ????
                people.filter(
                  person =>
                    person.age > 10 &&
                    person.firstName.length > 2 &&
                    person.lastName.length > 4
                )
              Сообщение отредактировано: applegame -
                Цитата Jin X @
                Ну что это за "красота" такая?

                Думаю, что тут имелся в виду принцип о размещении реакции на нарушения предусловий и обработки "внешних" ошибок в начале функций/методов.
                Как правило это действительно улучшает читаемость, поскольку дальнейшеая логика становится более простой.

                Добавлено
                Цитата Jin X @
                И вот такие слова в конце статьи:
                Цитата
                «Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось.

                С таким мышлением закон Вирта совершенно не кажется "шуткой":
                Цитата
                Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее

                Ну портить код без оснований для улучшения производительности действительно не стоит. И вполне допустимо улучшить его там, где скорость не критична.

                Добавлено
                Цитата Jin X @
                Но представим, что мы пишем библиотеку и не знаем как она будет использоваться.

                Совсем не знаем? Тогда зачем пишем? :D

                Добавлено
                Цитата Jin X @
                Реально ли (почти) всегда стоит заменять:
                ExpandedWrap disabled
                  // ????
                  people
                    .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4)
                на:
                ExpandedWrap disabled
                  // ????
                  people
                    .filter(person => person.age > 10)
                    .filter(person => person.firstName.length > 2)
                    .filter(person => person.lastName.length > 4)
                ради лучшей читабельности? И т.д.

                А здесь лучше читабельность? :D
                  Цитата Jin X @
                  Второй вариант чуть более сложный для понимания (спасибо разработчикам Python'а за отсутствие do-while/repeat-until), но и чуть более оптимальный по скорости
                  Какой же он оптимальный? Тут в каждом цикле два деления, когда можно обойтись одним.
                    Цитата amk @
                    Тут в каждом цикле два деления
                    2 деления во внешне цикле, 2 во внутреннем. Во втором примере при невыполнении условия внешнего цикла деление одно (в самом этом условии).
                    Цитата amk @
                    когда можно обойтись одним.
                    Мне вот даже интересно, как тут можно обойтись одним делением? :)

                    Добавлено
                    А, ну вот вижу вроде в питоне есть функция divmod, но это для внешнего цикла только... а дальше?

                    Добавлено
                    Хотя нифига, divmod, как оказалось, работает медленнее (даже медленнее 2 вызовов: % и //)

                    Добавлено
                    Причём, я сейчас замерил скорость Example1 и Example2 (причём, с умножением, а не с делением result'а). Разница более 30%, о как!
                      Цитата Jin X @
                      Хотя нифига, divmod, как оказалось, работает медленнее (даже медленнее 2 вызовов: % и //)
                      Т ак ты же вроде просил не обращать внимания на язык. В Си оптимизатор заменяет пару % / на одно деление. Вынесение одной из этих двух операций может сломать оптимизацию.

                      В любом случае нет смысла огород городить из-за всего одного сэкономленного деления. Судя по всему, это деление мало на что влияет.
                        Цитата D_KEY @
                        Совсем не знаем? Тогда зачем пишем?
                        Вот написал кто-то функцию power. Сразу понятно, где она может использоваться? :)

                        Добавлено
                        Цитата amk @
                        Т ак ты же вроде просил не обращать внимания на язык.
                        :lol:
                        Ну код же не на Си :)
                        Но в любом случае % во внутреннем цикле и result /= k ты одним делением не сделаешь.

                        Добавлено
                        Но мы от сути вопроса отошли...
                          Цитата Jin X @
                          Цитата D_KEY @
                          Совсем не знаем? Тогда зачем пишем?
                          Вот написал кто-то функцию power. Сразу понятно, где она может использоваться? :)

                          Да, практически везде, где будет применим сам язык. Значит это будет где-то в стандартной библиотеке и должно работать приемлемо во всех нишах, на которые рассчитан язык :)
                            Цитата Jin X @
                            parseOne('code_1','js',false)preloadCodeButtons('1');Ну что это за "красота" такая?

                            Тут видимо конфликт рекомендаций. Должно быть
                            ExpandedWrap disabled
                              const fetchData = (id) => {
                                if (!id)  return;
                                fetch('/data/' + id)
                              }


                            Но это противоречит безопасности if без else. Да и return по серёдке кода.

                            ExpandedWrap disabled
                              . . .
                                while i*i <= n:
                                  if n % i == 0:
                                    k = 3
                                    while 1:
                                      n //= i
                                      if n % i: break
                                      k += 2
                                    result /= k
                                  i += 1
                              . . .

                            Цитата Jin X @
                            Второй вариант чуть более сложный для понимания (спасибо разработчикам Python'а за отсутствие do-while/repeat-until),

                            Так там другой подход через множества.
                            Данный код лишён контекста(окружения) поэтому сказать как его от рефакторить трудно. Но как минимум он напрашивается на разбиение на 2 функции. Скорее всего эти 2 функции можно нормально поименовать, внутрь вставить ваши оптимизации. А для того что-бы вызов функций не тормозил сделать их через шаблоны.

                            Цитата Jin X @
                            Собственно, можно особо не заморачиваться и использовать первый вариант. Но представим, что мы пишем библиотеку и не знаем как она будет использоваться. Насколько критична будет скорость в финальном коде?

                            Это смотря как писать. Вот к примеру есть математическая библиотека eigen легко читаемая оптимизированная и не уступает по скорости конкурентам.
                            Или взять agg тоже качественный код. На самом деле я у себя сформировал комплект исходных кодов, которые счёл наиболее качественными.

                            Цитата Jin X @
                            Ваши мысли обо всём этом безобразии...

                            Считаю что надо стараться писать как можно более понятный код. Почему стараться? Потому что те библиотеки, которые я назвал появились не на пустом месте до них были другие библиотеки, которые имели плохой код. Во-вторых надо писать только то что нужно не делать код на будущее. Код развивается и постепенно наполняет новыми функциями но в тоже время код подлежит рефакторенгу. Тот же OpenCV переживает уже 4 версию. Каждая версия не совместима с другой потому что отрефакторина убран плохой код убраны подпорки.
                            Правда OpenCV не дотягивает до качественного кода, так как содержит нечитаемый код. В этом плане AForge.NET мне больше нравится (Си#),
                              Цитата Jin X @
                              Ну что это за "красота" такая?

                              Очевидно, что второй вариант на порядок лучше, хз что тебе не нравится :-?

                              Добавлено
                              Цитата Pavia @
                              Тут видимо конфликт рекомендаций. Должно быть

                              Фигурные скобки опускать никогда нельзя :yes:
                                Цитата Serafim @
                                Фигурные скобки опускать никогда нельзя
                                Никогда не говори "никогда". :yes:
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (7) [1] 2 3 ...  6 7 все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0604 ]   [ 16 queries used ]   [ Generated: 28.03.24, 13:14 GMT ]