Pull to refresh

Comments 21

Код должен быть самодокументируемым!

Третья плохая практика: импортируйте по максимуму… если вы пишете на JS или PHP...

A если мы пишем не на JS или PHP? Это всё ещё будет плохой практикой? :)

Если вас травят в пул-реквестах за сокращения в именах переменных и функций, то можно схитрить. Вместо того чтобы создавать маленькие функции в ограниченном контексте, можно писать портянки с красноречивыми именами из префиксов и суффиксов. Делайте вид, что следуете заветам Стива Макконнелла. Например `discountedProducts` или даже `discountedProductsForUncofirmedUsers`.
С отдельным усердием нужно отнестись к случаям, когда используются математические формулы. Нет ничего приятнее, чем читать формулу с шестью и более переменными, каждая из которых — не менее 4 слов. Ещё лучше, если нет пробелов вокруг операторов.

Никто не мешает сложные формулы считать по частям.
Легче отлаживать.
Легче читать.
Компилятору пофиг (соптимизирует).
Подконтрольный процесс переполнений и потерь точности.
Машинная запись формулы и бумажная — преследуют разные цели. Бумажная — удобство понимания (подстановок и преобразований) и ручных вычислений. Машинная — удобство отладки, повышение скорости, избежания потерь при преобразованиях и переполнениях.

Формулы лучше всего писать максимально близко к тому, как они написаны на бумаге. И в комментариях — ссылку на статью, откуда формулы взялись, или краткое описание, как они выводятся.

Я бы поспорил с частью утверждения. С ссылками на источник полностью согласен. Но вот попытка линейно записать двумерный рисунок формулы только запутывает. Сумма последовательности определенных интегралов на бумаге выглядит красиво и понятно. В коде пытаться повторить этот рисунок, мне кажется, не стоит.

Формулы поддерживает лишь wolfram и подобный математические языки. На других писать формулы невероятно неудобно и нечитаемо. Более менее удобно на F# и прочих функциональных языках.

Обычно оставляют ссылку на саму формулу на сайте. А переменные называют строго как по ссылке.

Я больше всего страдал из-за отсутствия многоэтажного деления и индексов (для них даже Wolfram Mathematica не помогает — там нельзя писать всякие F_{sx}).

В F#, Ocaml и Haskell функции, начинающиеся с заглавной буквы — это конструкторы. Поэтому уже формулу для ускорения свободного падения через массу Земли писать не очень удобно. А Ocaml вообще для плавающей точки неудобен, т.к. по-умолчанию там арифметические операторы для плавающей точки выглядят как +. -. *. /.

Хотя, конечно, функциональные языки очень удобны тем, что функции можно и нужно передавать в функции.

Эти все советы работают в отсталых командах, которые работают без код-ревью. Либо если вы работаете в одиночку, и планируете оставить такой код потомкам :)

Возможно, вы захотите сократить три строки кода до одной при помощи хитроумного тернарного оператора с тройным вложением. Дайте волю своему воображению!

Тройного не было, а вот двойным недавно согрешил, пошел посыпать голову пеплом :(

Возьмите любой стартап до 4 лет. Да и старше, если стартап все еще не выстрелил и нет денег на переписывание. Там будет все это и еще больше. Вот вам навскидку:

  1. Логи? Нахрен надо. Х...к х..к и в продакшен. Кому нужны эти логи?

  2. Тернарный оператор - чем длиннее строка тем лучше. А еще если там функция вызывает функцию с параметром где тоже тернарный оператор и вызывается другая функция - это будет вишенкой на торте.

  3. Прочитал про функциональное программирование? Давай засовывай замыкание и каррирование где надо и где не надо. А, мутации... точно, делай клон всему и вся, память то бесконечная. А еще ко всему этому прицепи какую нибудь либу типа рамды и стримов, чтобы никто не смог продебажить это творение.

  4. Используй везде и только примитивы и булианы. Ведь если функция которая что-то проверяет возвращает false, вряд ли завтра или даже сегодня ты захочешь знать почему она вернула false. А передавать 10+ параметров в функцию однозначно лучше упаковки их в объект... объекты они страшные. А деньги можно и в переменно price передавать. И рядом отдельную переменную currency. Зачем еще один лишний объект в системе.

  5. Возвращай разные объекты из функций. Это круто когда ты можешь получить массив когда результатов много, и один объект когда результат один.

  6. Так же у тебя есть возможно назвать параметр функции 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()


ну, удачи вашей команде, я бы у вас работать не стал
Sign up to leave a comment.