Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.62.131] |
|
Страницы: (7) [1] 2 3 ... 6 7 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Много статей развелось про чистоту кода (на основе книги Р.Мартина и не только). В целом концепция, конечно, хорошая.
Но бывают какие-то прямо абсурдные, ИМХО, рекомендации. Вот к примеру тут: // ???? const fetchData = (id) => { if (id) { fetch('/data/' + id) } } // ???? const fetchData = (id) => { if (!id) { return } fetch('/data/' + id) } И вот такие слова в конце статьи: Цитата «Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось. С таким мышлением закон Вирта совершенно не кажется "шуткой": Цитата Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее Далее, второй момент. Более "тонкий", скажем так. Example1 (кусочек кода): . . . while i*i <= n: k = 1 while n % i == 0: k += 2 n //= i result /= k i += 1 . . . Example2 (кусочек кода): . . . 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++ ). Собственно, можно особо не заморачиваться и использовать первый вариант. Но представим, что мы пишем библиотеку и не знаем как она будет использоваться. Насколько критична будет скорость в финальном коде? Ваши мысли обо всём этом безобразии... |
Сообщ.
#2
,
|
|
|
Не читай плохих статей! Создавать Elephantware имеет смысл только тогда, когда ты в пожизненной разработке проекта, и тебе оплачивают не качество, а количество доработок.
|
Сообщ.
#3
,
|
|
|
Цитата Jin X @ Не углубляйтесь в суть алгоритма, это неважно. как это не углубляйтесь? возможно там вообще деление не нужно |
Сообщ.
#4
,
|
|
|
Цитата villain @ Суть вообще не в этом. Будем считать, что алгоритм достаточно оптимален (это часть кода разложения на простые множители и манипуляции с ними), но есть 2 вот таких варианта реализации как это не углубляйтесь? возможно там вообще деление не нужно Там вообще умножение должно быть, я заменил его на деление для пущего эффекта |
Сообщ.
#5
,
|
|
|
Цитата JoeUser @ Не, ну понятно, что создавать класс в 3 поколения с 10 методами в каждом там, когда нужно сделать просто min(x,y) - это бред. Речь идёт именно о чистоте кода, а не о заделе на будущее. Т.е. о понятности кода тебе и людям с возможностью лёгкой модификации.Создавать Elephantware имеет смысл только тогда, когда ты в пожизненной разработке проекта, и тебе оплачивают не качество, а количество доработок. Реально ли (почти) всегда нужно писать одно действие-одна функция и выстраивать 5-этажные вызовы там, где можно было бы обойтись одной функцией? Реально ли (почти) всегда стоит заменять: // ???? people .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4) // ???? people .filter(person => person.age > 10) .filter(person => person.firstName.length > 2) .filter(person => person.lastName.length > 4) |
Сообщ.
#6
,
|
|
|
Цитата Jin X @ Реально ли (почти) всегда стоит заменять: // ???? people .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4) // ???? people .filter(person => person.age > 10) .filter(person => person.firstName.length > 2) .filter(person => person.lastName.length > 4) Можно еще вот так // ???? people.filter( person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4 ) |
Сообщ.
#7
,
|
|
|
Цитата Jin X @ Ну что это за "красота" такая? Думаю, что тут имелся в виду принцип о размещении реакции на нарушения предусловий и обработки "внешних" ошибок в начале функций/методов. Как правило это действительно улучшает читаемость, поскольку дальнейшеая логика становится более простой. Добавлено Цитата Jin X @ И вот такие слова в конце статьи: Цитата «Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось. С таким мышлением закон Вирта совершенно не кажется "шуткой": Цитата Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее Ну портить код без оснований для улучшения производительности действительно не стоит. И вполне допустимо улучшить его там, где скорость не критична. Добавлено Цитата Jin X @ Но представим, что мы пишем библиотеку и не знаем как она будет использоваться. Совсем не знаем? Тогда зачем пишем? Добавлено Цитата Jin X @ Реально ли (почти) всегда стоит заменять: // ???? people .filter(person => person.age > 10 && person.firstName.length > 2 && person.lastName.length > 4) // ???? people .filter(person => person.age > 10) .filter(person => person.firstName.length > 2) .filter(person => person.lastName.length > 4) А здесь лучше читабельность? |
Сообщ.
#8
,
|
|
|
Цитата Jin X @ Какой же он оптимальный? Тут в каждом цикле два деления, когда можно обойтись одним. Второй вариант чуть более сложный для понимания (спасибо разработчикам Python'а за отсутствие do-while/repeat-until), но и чуть более оптимальный по скорости |
Сообщ.
#9
,
|
|
|
Цитата amk @ 2 деления во внешне цикле, 2 во внутреннем. Во втором примере при невыполнении условия внешнего цикла деление одно (в самом этом условии).Тут в каждом цикле два деления Цитата amk @ Мне вот даже интересно, как тут можно обойтись одним делением? когда можно обойтись одним. Добавлено А, ну вот вижу вроде в питоне есть функция divmod, но это для внешнего цикла только... а дальше? Добавлено Хотя нифига, divmod, как оказалось, работает медленнее (даже медленнее 2 вызовов: % и //) Добавлено Причём, я сейчас замерил скорость Example1 и Example2 (причём, с умножением, а не с делением result'а). Разница более 30%, о как! |
Сообщ.
#10
,
|
|
|
Цитата Jin X @ Т ак ты же вроде просил не обращать внимания на язык. В Си оптимизатор заменяет пару % / на одно деление. Вынесение одной из этих двух операций может сломать оптимизацию.Хотя нифига, divmod, как оказалось, работает медленнее (даже медленнее 2 вызовов: % и //) В любом случае нет смысла огород городить из-за всего одного сэкономленного деления. Судя по всему, это деление мало на что влияет. |
Сообщ.
#11
,
|
|
|
Цитата D_KEY @ Вот написал кто-то функцию power. Сразу понятно, где она может использоваться? Совсем не знаем? Тогда зачем пишем? Добавлено Цитата amk @ Т ак ты же вроде просил не обращать внимания на язык. Ну код же не на Си Но в любом случае % во внутреннем цикле и result /= k ты одним делением не сделаешь. Добавлено Но мы от сути вопроса отошли... |
Сообщ.
#12
,
|
|
|
Цитата Jin X @ Цитата D_KEY @ Вот написал кто-то функцию power. Сразу понятно, где она может использоваться? Совсем не знаем? Тогда зачем пишем? Да, практически везде, где будет применим сам язык. Значит это будет где-то в стандартной библиотеке и должно работать приемлемо во всех нишах, на которые рассчитан язык |
Сообщ.
#13
,
|
|
|
Цитата Jin X @ parseOne('code_1','js',false)preloadCodeButtons('1');Ну что это за "красота" такая? Тут видимо конфликт рекомендаций. Должно быть const fetchData = (id) => { if (!id) return; fetch('/data/' + id) } Но это противоречит безопасности if без else. Да и return по серёдке кода. . . . 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 мне больше нравится (Си#), |
Сообщ.
#14
,
|
|
|
Цитата Jin X @ Ну что это за "красота" такая? Очевидно, что второй вариант на порядок лучше, хз что тебе не нравится Добавлено Цитата Pavia @ Тут видимо конфликт рекомендаций. Должно быть Фигурные скобки опускать никогда нельзя |
Сообщ.
#15
,
|
|
|
Цитата Serafim @ Никогда не говори "никогда". Фигурные скобки опускать никогда нельзя |