Истоки

Когда-то давно JavaScript разработчики очень любили использовать анонимные функции (собственно и сейчас многие их любят использовать), и всё бы ничего, и код становится короче, и не надо придумывать очередное название для функции, но рано или поздно это превращается в “водопад функций” прочитать который вы сможете разве только в хорошем IDE и то немного поломав голову.

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

Вы, возможно, помните недавний анонс нового статического анализатора для Go под названием go-critic.

Я проверил с его помощью проект golang/go и отправил несколько патчей, которые исправляют некоторые найденные там проблемы.

В этой статье мы разберём исправленный код, а также будем мотивироваться отправлять ещё больше подобных изменений в Go.

Для самых нетерпеливых: обновляемый список трофеев.

Привет, Хабр! Предлагаю вашему вниманию авторский перевод страницы документации Kotlin Coding Conventions от JetBrains.

→ Оригинал документации

Если вам не приходилось работать в команде, то, возможно, вы еще не используете эти вещи, а кто-то даже не знает про них. Работая один, вы сами себе хозяин.

Как только начали работать в команде  —  ситуация резко меняется. Если нет договоренностей, то каждый начинает писать код в таком стиле, в каком умеет. И даже если вы все же собрались и обсудили на словах codestyle на проекте и даже записали где-то, это, скорее всего, не поможет решить проблему, и вот почему.

ansible devops codestyle

Hey! Меня зовут Денис Калюжный я работаю инженером в отделе автоматизации процессов разработки. Каждый день новые сборки приложений раскатываются на сотнях серверов кампании. И в этой статье я делюсь опытом использования Ansible для этих целей.

Этот гайд предлагает способ организации переменных в деплое. Рассчитан данный гайд на тех кто уже использует роли в своих плейбуках и читал BestPractices, но сталкивается с подобными проблемами:

• Найдя переменную в коде, невозможно сходу понять за что она отвечает;
• Есть несколько ролей, и переменные нужно связать одним значением, но никак не получается;
• Возникают трудности в объяснении другим, как устроена логика переменных в ваших плейбуках

С этими проблемами мы столкнулись на проектах в нашей компании, в следствие чего мы пришли к правилам оформления переменных в наших плейбуках, которые в какой-то мере решили эти проблемы.

Данная статья охватывает не только эстетические вопросы форматирования, но и другие типы соглашений и стандартов, которые необходимо знать Android разработчику.

Основной фокус, в первую очередь, на жестких правилах, которым следуют Google разработчики повсеместно!

Сначала я думал, что статья будет небольшой, но из-за слишком колоссального количества примеров кода она достаточно выросла.

Поэтому я решил разделить её на две части.

Обе части содержат описание стандартов кода на языке программирования Kotlin.

В принципе, я согласен с комментариями, что данная тема излишняя, так как существуют автоматические инструменты форматирования кода

И к тому же у каждого своё мнение о красоте и эстетичности, поэтому coding style носит субъективный характер.

Но я все таки решил закончить данную серию статей по Kotlin стилю, как и обещал.

Возможно кому-нибудь пригодится.

Ну что ж прошу под кат!

Довольно часто сталкиваюсь с одним вопросом касательно кода: "Почему написано именно так, а не так?". И я объясняю чем это обусловлено, после чего слушаю мнение оппонента, вследствие чего принимаю решение либо продолжать следовать своим установкам, либо менять на более лучший вариант.

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

Когда проект на python долгое время живет без правил по формату строк, то в один прекрасный момент оказывается, что 90% кода используют одинарные кавычки, а 10% - двойные.

Добавление flake8-quotes с соответствующими правилами перестало пускать новый код с двойными кавычками дальше пул-реквеста, но начало требовать ручной правки формата в уже существующем коде, чего хотелось бы избежать.

Первой мыслью было задействовать black, но предлагаемый им формат предполагает исключительно использование двойных кавычек. В 2018 в github black был запрос Single quotes option формата строк, обсуждение было жарким, но закончилось оно лишь введением опции --skip-string-normalization, позволявшей не трогать формат строк в проверяемом коде.