Комментарии 13
Интересный взгляд на красоту кода.
Красивый код, это когда всё по феншую. А понятия о феншуе у каждого свои. Со своим уставом в чужой монастырь не ходят, поэтому общий вывод такой, что люди совместно работающие над одной кодовой базой должны иметь договорённости о том как код оформлять и какими методами (архитектурными шаблонами) решать стандартные задачи, договорённость о том как всё в целом должно быть организовано (архитектура приложения в целом)
Красивый код, это когда всё по феншую. А понятия о феншуе у каждого свои. Со своим уставом в чужой монастырь не ходят, поэтому общий вывод такой, что люди совместно работающие над одной кодовой базой должны иметь договорённости о том как код оформлять и какими методами (архитектурными шаблонами) решать стандартные задачи, договорённость о том как всё в целом должно быть организовано (архитектура приложения в целом)
Хабрапользователи, а в каких проектах по вашему мнению максимально красивый код?
В тех, которые ты хочешь начать, но откладываешь, обещая начать в понедельник.
«Уж новый проект я точно не запорю и сделаю идеально» — говоришь ты сам себе.
Но проходит день за днем, а проект не начат, потому что ты еще не готов писать идеальный код.
«Уж новый проект я точно не запорю и сделаю идеально» — говоришь ты сам себе.
Но проходит день за днем, а проект не начат, потому что ты еще не готов писать идеальный код.
Помню, смотрел код утилиты GNU ls — офигел, насколько все красиво и понятно написано.
При этом код красивый, но буквально каждое правило форматирования, которым они пользуются, вызывает у меня отторжение. :)
ЗЫ: Посмотрел сейчас в тот код — мама дорогая… Ужас же. Но тогда я, помню, насмотрелся кода всяческих драйверов на Си, вот глазыньки и вытекли…
При этом код красивый, но буквально каждое правило форматирования, которым они пользуются, вызывает у меня отторжение. :)
ЗЫ: Посмотрел сейчас в тот код — мама дорогая… Ужас же. Но тогда я, помню, насмотрелся кода всяческих драйверов на Си, вот глазыньки и вытекли…
Когда-то я заморачивался этим вопросом. Потом дошел до более практичного — если проект работает и делает что-то крутое крутым способом, то вообще плевать, насколько «красив» его код. Пусть там даже будут костыли для костылей кругом.
Вот знаю, где очень некрасивое API — devextreme-react-grid. Мало того, что половина логики лежит внутри JSX, так еще и, чтобы реализовать одну из out-of-box фич, как поиск по таблице и выбор строк, нужно:
a) вставить несколько JSX-компонентов (каких — читай документацию, обработку ошибок не придумали)
б) сделать это в определенном порядке (иногда в консоли появится ошибка о неправильном порядке вызове функций)
в) понять, что эти разные компоненты связаны только по соглашению в названии переменных
г) потом понять, что это работает не всегда: для SelectionState нужен IntegratedSelection, а для SearchState уже нужен IntegratedFiltering.
в) написать пару goto конструкций (шутка)
a) вставить несколько JSX-компонентов (каких — читай документацию, обработку ошибок не придумали)
б) сделать это в определенном порядке (иногда в консоли появится ошибка о неправильном порядке вызове функций)
в) понять, что эти разные компоненты связаны только по соглашению в названии переменных
г) потом понять, что это работает не всегда: для SelectionState нужен IntegratedSelection, а для SearchState уже нужен IntegratedFiltering.
в) написать пару goto конструкций (шутка)
По сути, антипаттерн — паттерн, который не следует использовать. Но, тем не менее, это паттерн, который определенным образом придает читаемости и понимаемости, то есть простоты и красоты коду.
Ага, антипаттерн «спагетти-код» придает программе особую читабельность… :)
Выходит дело, что ее нужно просто научить тому, что вы хотите, и впоследствии она станет для вас незаменимым помощником, который сэкономит вам кучу времени.
А потом разработчик приходит в команду хардкорных серверных разработчиков, у которых из IDE — только Vim в консольке… Слезы, паника, отрицание, гнев, торг, принятие — и катарсис…
Очень много it компаний по всему миру пренебрегают написанием документа, стандартизирующего стиль кода.
Хм… А у меня другое впечатление: сначала пишется кодинг-стайл-гайд, а уже потом создается IT-компания. :)
А вот уже потом происходит то, о чем вы пишете: в каждой команде сей стайл-гайд творчески перерабатывается, и в результате каждая команда пишет по-своему.
О качестве (я считаю, что красивый код прежде всего качественный код) лучше всего сказано в "Дзен и искусство ухода за мотоциклом". Суть в том, что качество невозможно определить формальными правилами, хотя многие могут определить качественен результат или нет.
Директива #region #endregion позволяет указывать блоки кода, которые можно будет сворачивать в IDE.
Я видел использование этой директивы, чтобы спрятать большие строки (например GraphQL-запрос на другой сервис), чтобы остальную часть кода можно было нормально читать. Причем в идеале такие запросы вынести в отдельный класс (или XML), но в ситуации с отдельным классом все-равно имеет смысл запаковать в region, наверное
Я бы применил к статье принципы, в ней описанные, и тем самым сократил бы ее раз в 10. А вместо простанных рассуждений вставил бы примеры красивого кода.
Для меня красивый код это прежде всего эффективный и алгоритмически-верный код. У программистов есть своя профессиональная болезнь, от которой трудно излечиться — графоманство. Программист-графоман это угроза всей IT-индустрии, так как такие как он заботятся о красоте написанного кода, о том как выглядит он в редакторе, а не о том, как он работает в реальной жизни. Потребитель не смотрит ваш код, он смотрит на конечный результат. И если ваш красивый код убивает Боинг и всех пассажиров, то от такой «красоты» лучше держаться подальше…
Beauty of style and harmony and grace and good rhythm depend on simplicity — Платон
Платон писал на современном английском? И вправду гений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размышления о красоте и коде