Comments 21
Третья плохая практика: импортируйте по максимуму… если вы пишете на JS или PHP...
A если мы пишем не на JS или PHP? Это всё ещё будет плохой практикой? :)
Никто не мешает сложные формулы считать по частям.
Легче отлаживать.
Легче читать.
Компилятору пофиг (соптимизирует).
Подконтрольный процесс переполнений и потерь точности.
Машинная запись формулы и бумажная — преследуют разные цели. Бумажная — удобство понимания (подстановок и преобразований) и ручных вычислений. Машинная — удобство отладки, повышение скорости, избежания потерь при преобразованиях и переполнениях.
Формулы лучше всего писать максимально близко к тому, как они написаны на бумаге. И в комментариях — ссылку на статью, откуда формулы взялись, или краткое описание, как они выводятся.
Я бы поспорил с частью утверждения. С ссылками на источник полностью согласен. Но вот попытка линейно записать двумерный рисунок формулы только запутывает. Сумма последовательности определенных интегралов на бумаге выглядит красиво и понятно. В коде пытаться повторить этот рисунок, мне кажется, не стоит.
Формулы поддерживает лишь wolfram и подобный математические языки. На других писать формулы невероятно неудобно и нечитаемо. Более менее удобно на F# и прочих функциональных языках.
Обычно оставляют ссылку на саму формулу на сайте. А переменные называют строго как по ссылке.
В F#, Ocaml и Haskell функции, начинающиеся с заглавной буквы — это конструкторы. Поэтому уже формулу для ускорения свободного падения через массу Земли писать не очень удобно. А Ocaml вообще для плавающей точки неудобен, т.к. по-умолчанию там арифметические операторы для плавающей точки выглядят как +. -. *. /.
Хотя, конечно, функциональные языки очень удобны тем, что функции можно и нужно передавать в функции.
Эти все советы работают в отсталых командах, которые работают без код-ревью. Либо если вы работаете в одиночку, и планируете оставить такой код потомкам :)
Возможно, вы захотите сократить три строки кода до одной при помощи хитроумного тернарного оператора с тройным вложением. Дайте волю своему воображению!
Тройного не было, а вот двойным недавно согрешил, пошел посыпать голову пеплом :(
Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:
Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?
Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.
Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.
Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.
Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.
Так же у тебя есть возможно назвать параметр функции listingId, и в функции проверять если там массив то делай одно, а если нет - другое. Ведь нет вероятности того что следующая функция будет понимать только стринг а не массив, и что кто-то просто туда предаст это переменную.
Проходясь по легаси коду стартапов где главное - быстро в продакшен все пихнуть, можно книгу написать...
Я сейчас в параллельной реальности занимаюсь поддержкой деревенского дома построенного по принципу такого стартапа. И одна из сложностей такой поддержки, что заказчик просит поддержку и дальнейшее развитие проводить в такой же идеологии. Хорошо, что инвестор данного проекта все-таки я, а не заказчик.
Действительно, и проект и команда должны вызреть. То есть столкнуться с эксплуатацией и долгосрочной поддержкой своего же продукта. И как всегда, большинство учатся на своих ошибках. Новичков в команде к сожалению давят авторитетом и традициями. Когда есть возможность (в основном — время) стараюсь на попытки исполнить задачу "по вредным советам" приводить реальные антипримеры из жизни.
плюс. если используют базы данных. то и таблицы названы, атрибуты в них итд. - без логики и адекватное кол-во времени не позволит во всём разобраться. И как в вашем примере, и в похожих ситуациях - проще всё переписать заново, чем разбираться в дебрях. К сожалению.
Вот какой смысл этой сатирической статьи? Чисто зловеще похохотать?
Нужны примеры говнокода, нужны примеры исправления говнокода.
Так-то для порчи отношений может быть достаточно #define true false, wish you happy debug.
создавать что-нибудь в духе readXmlDocument
readExtensibleMarkupLanguageDocument же
Дополнительно усложнить восприятие помогут ненужные сокращения типа btn, func, config
То есть автор настаивает на использовании несокращенных вариантов — button, function, configuration? Ну, хочется спросить автора — вы свои рассуждения из какой-либо практики черпаете или ваши «очень полезные советы» имеют чисто теоретический характер? Начать с того, что function например, это зарезервированное слово языка в JS, то есть как минимум для частных случаев ваши рекомендации неприменимы. Кроме того, я не представляю себе идиота, которого бы могли смутить данные сокращения. Хмм, func, какое странное слово, чтобы это могло означать? Может быть это Фунтик? Или это португальское слово funce? Может я не понял смысла статьи? За стилем трудно угадать, то ли автор сейчас шутит искрометно, толи это какой-то многослойный сарказм, но у меня такое чувство, что статья целиком высосана из пальца. Если же в вашей дружной команде и правда кто-то агрится на
for btn in buttons:
btn.disable()
ну, удачи вашей команде, я бы у вас работать не стал
Пять худших практик написания кода, которые помогут испортить отношения с коллегами