Но бывают какие-то прямо абсурдные, ИМХО, рекомендации.
Вот к примеру тут:
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
Ну что это за "красота" такая?// ????
const fetchData = (id) => {
if (id) {
fetch('/data/' + id)
}
}
// ????
const fetchData = (id) => {
if (!id) {
return
}
fetch('/data/' + id)
}
И вот такие слова в конце статьи:
Цитата
«Погодите! А как насчет изменения производительности?». Мне это безразлично. Правда. Разве что есть реальная проблема, когда приложение становится медленнее, чем ожидалось.
С таким мышлением закон Вирта совершенно не кажется "шуткой":
Цитата
Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее
Далее, второй момент. Более "тонкий", скажем так.
Example1 (кусочек кода):
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
. . .
while i*i <= n:
k = 1
while n % i == 0:
k += 2
n //= i
result /= k
i += 1
. . .
Example2 (кусочек кода):
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
Не углубляйтесь в суть алгоритма, это неважно.. . .
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++
).Собственно, можно особо не заморачиваться и использовать первый вариант. Но представим, что мы пишем библиотеку и не знаем как она будет использоваться. Насколько критична будет скорость в финальном коде?
Ваши мысли обо всём этом безобразии...
Создавать Elephantware имеет смысл только тогда, когда ты в пожизненной разработке проекта, и тебе оплачивают не качество, а количество доработок. 
Ты уверен? 