#стиль_кода — Public Fediverse posts

[Перевод] PEP 8 как религия: почему Python сам не соблюдает свои же правила

Команда Python for Devs подготовила перевод статьи о PEP 8. Мысль проста: споры о стиле в Python часто сводятся к одному — snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?

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

#Python #PEP8 #стиль_кода #читаемость #snake_case #camelCase #закон_Свейгарта #правила #разработчики #open_source

[Перевод] PEP 8 как религия: почему Python сам не соблюдает свои же правила

Команда Python for Devs подготовила перевод статьи о PEP 8. Мысль проста: споры о стиле в Python часто сводятся к одному — snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?

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

#Python #PEP8 #стиль_кода #читаемость #snake_case #camelCase #закон_Свейгарта #правила #разработчики #open_source

[Перевод] PEP 8 как религия: почему Python сам не соблюдает свои же правила

Команда Python for Devs подготовила перевод статьи о PEP 8. Мысль проста: споры о стиле в Python часто сводятся к одному — snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?

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

#Python #PEP8 #стиль_кода #читаемость #snake_case #camelCase #закон_Свейгарта #правила #разработчики #open_source

[Перевод] PEP 8 как религия: почему Python сам не соблюдает свои же правила

Команда Python for Devs подготовила перевод статьи о PEP 8. Мысль проста: споры о стиле в Python часто сводятся к одному — snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?

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

#Python #PEP8 #стиль_кода #читаемость #snake_case #camelCase #закон_Свейгарта #правила #разработчики #open_source

Flutter. Стиль кода — это все

Стиль кода — это все. Это свежий взгляд на простое и сложное. Стильный, но простой код лучше, чем сложный, но не стильный. Сложный и стильный — это искусство. Разработка может быть искусством, тестирование может быть искусством. Оптимизация кода — тоже искусство. Не все придерживаются стиля, да и не у всех он есть. В коде может быть больше стиля, чем в дизайне, но не у всего кода есть стиль. Фреймворки безмерно стильные. Когда разработчик находит идеальное сочетание функциональности и читаемости в своем коде, это стильно. Люди тоже диктуют стиль. Стиль был у Роберта Мартина, у Дэвида Томаса, у Мартина Фаулера, у Эрика Эванса... Я встречал стиль в открытом исходном коде. В среде разработчиков стильных проектов куда больше, чем в каком-либо другом сообществе. Стиль — это атрибут, подход и структура. Выше – юмористическая интерпретация слов из поэмы Чарльза Буковски «Стиль». Вариативность стиля кода настолько многогранна, что не всегда удается прийти к единому мнению в пользу того или иного подхода, поэтому стиль в сегодняшнем понимании — это целая культура. Сегодня мы будем разматывать клубок лучших практик и скрытых трюков. После этого ваш код станет не просто рабочим, а настоящим произведением искусства. С учетом моего опыта работы мобильным разработчиком в TAGES, я готов поделиться своими знаниями и практиками, которые могут быть полезны для вашего проекта. Пристегнитесь потуже — мы взлетаем!

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

#Flutter #Dart #mobile_development #кроссплатформенная_разработка #мобильная_разработка #best_practices #code_style #стиль_кода #лучшие_практики #flutter_mobile_development

[Перевод] История переформатирования 100 000+ файлов Google в 2012 году

В сентябре далёкого 2012 года я трудился начинающим инженером в Google, занимаясь разработкой Bazel (инструмент сборки, внутри компании также известный под именем Blaze). Однажды мне на почту пришло загадочное приглашение из Google Календаря. Его прислали два инженера из США, пригласив на встречу меня и моего тимлида. Я сразу узнал имена отправителей — это были Роб Пайк и Расс Кокс. И хотя работать мне с ними не доводилось, я был о них наслышан. Расса Кокса я знал по его блогу, который любил читать, а Роба Пайка просто, потому что он известен. В ходе встречи они поделились с нами своим амбициозным планом: переформатировать каждый BUILD-файл Bazel в кодовой базе Google с помощью автоматизированного скрипта.

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

#ruvds_перевод #go #google #форматирование_кода #программирование #стиль_кода #bazel #buildifier

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

Давайте представим нереалистичный сценарий, где вы выбираете язык программирования для проекта, который в перспективе станет очень большим. Допустим, это будет набор сервисов в монорепозитории, над которыми работает более 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 #оформление_кода #стиль_кода

Красота не только в коде — как оформлять репозиторий

Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код. Все, что вы увидите в данной статье, будет касаться прочитанных мною материалов и полученного опыта. В мире разработки программного обеспечения правильное оформление документации играет ключевую роль в обеспечении ясности и понятности проекта. Особенно важным этапом в этом процессе является создание и поддержание README файлов в Git репозиториях. README файлы - это первое, что увидит разработчик, приступая к работе с проектом, и хорошо оформленная документация может значительно упростить процесс взаимодействия с кодом. В данной статье мы рассмотрим ключевые аспекты оформления документации в Git репозитории, обсудим лучшие методики и практики для создания качественной документации. Независимо от того, являетесь ли вы опытным разработчиком или новичком в области Git, эта статья поможет вам создать четкую, структурированную и информативную документацию для вашего проекта. Погружайтесь в мир оформления документации, улучшайте ваши проекты и делитесь своими идеями с сообществом разработчиков Хабр! Узнать, как оформлять репозитории

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

#Стиль_кода #Git #Github #Документация #Оформление #Написание_документации #Чистый_код #код