#оформление_кода — Public Fediverse posts

Строки кода должны помещаться на экране

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

https://habr.com/ru/companies/pvs-studio/articles/971950/

#pvsstudio #статический_анализ #статический_анализ_кода #c# #рефакторинг #оформление_кода #информационная_безопасность #Space_Engineers #sast

Строки кода должны помещаться на экране

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

https://habr.com/ru/companies/pvs-studio/articles/971950/

#pvsstudio #статический_анализ #статический_анализ_кода #c# #рефакторинг #оформление_кода #информационная_безопасность #Space_Engineers #sast

Строки кода должны помещаться на экране

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

https://habr.com/ru/companies/pvs-studio/articles/971950/

#pvsstudio #статический_анализ #статический_анализ_кода #c# #рефакторинг #оформление_кода #информационная_безопасность #Space_Engineers #sast

Строки кода должны помещаться на экране

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

https://habr.com/ru/companies/pvs-studio/articles/971950/

#pvsstudio #статический_анализ #статический_анализ_кода #c# #рефакторинг #оформление_кода #информационная_безопасность #Space_Engineers #sast

Простые приёмы, которые сделают ваш код нагляднее

Упорядоченный, опрятный, хорошо написанный для восприятия код помогает быстрее выявлять случайные ошибки, и позволяет глазам быстрее " парсить " код, что в целом ускоряет время выполнения задач . В этой статье я, Андрей Рик, fullstack-разработчик с 10+ лет опыта коммерческой разработки, рассказываю как и зачем писать опрятный код. Читать статью

https://habr.com/ru/articles/831570/

#frontend #react #next #оформление_кода #best_practices #Андрей_Рик #junior #middle #code #код

[Перевод] Эффект Монреаля: почему языкам программирования нужен Царь стилей

Давайте представим нереалистичный сценарий, где вы выбираете язык программирования для проекта, который в перспективе станет очень большим. Допустим, это будет набор сервисов в монорепозитории, над которыми работает более 100 человек. Чтобы сделать этот сценарий ещё менее реалистичным, предположим, что вы игнорируете типичные ограничения, например, не учитываете, сможете ли использовать сборщик мусора, и впишется ли поставленная задача в конкретный стек технологий. Пусть это будет мысленный эксперимент. Подыграйте мне. Если вы читали мою прошлую статью (англ.) , то должны правильно предположить, что я бы предпочёл экспрессивный язык, ориентированный на профессионалов. Так и есть. Но в гибком языке программирования есть серьёзная проблема с масштабированием – слишком много стилей оформления кода и способов его написания. В итоге просто не обойтись без руководств по стилю, которые помогут сориентироваться в правильной реализации. Какое подмножество C++ или Kotlin вы используете? Что вы предпочтёте: project.toml или requirements.txt ? Теперь у вашего языка есть возможность поэтапной типизации с помощью аннотаций типов. Хотите ей воспользоваться? Как вы реализуете конкурентность: с помощью многопоточности, Tokio или std::async ? Чем более экспрессивный язык, тем сложнее всё становится. И здесь на сцену выходит Go. И речь не только о gofmt , но и о его стандартной библиотеке и согласованности. В Kotlin вам приходится гадать, что лучше использовать для ошибок: исключения или объекты Result ? В случае же Go вам всё ясно – ищем err . Да, это многословно, но зато предсказуемо. Экспрессивные языки прекрасны, но часто создают путаницу. Вы можете использовать богатый и комплексный язык, поддерживающий миллион способов реализации одного и того же. Именно это я хочу вам показать. Как же сохранить всю эту мощь, но уменьшить беспорядок? Как избежать возникновения 500 поддиалектов? Но прежде, чем переходить к решениям, обсудим Scala.

https://habr.com/ru/companies/ruvds/articles/805235/

#ruvds_перевод #программирование #scala #c++ #python #оформление_кода #стиль_кода

[Перевод] Делаем код-ревью правильно

В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира. И что вы думаете? Через несколько месяцев наша база кода стала подобна минному полю. Причём баги нас волновали меньше всего, хотя их была уйма. Реальная проблема заключалась в том, что никто не мог понять код, написанный другими. У нас во многих местах дублировалась логика, и в модулях использовались разные стили кода. Всё было очень печально. Тогда до нас дошло! Нужно взять всё под контроль. Код-ревью реально помогают сохранять код читаемым, обслуживаемым и масштабируемым. Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно . Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.

https://habr.com/ru/companies/ruvds/articles/803127/

#ruvds_перевод #программирование #кодревью #рефакторинг #оформление_кода