Привет, Хабр! Предлагаю вашему вниманию авторский перевод страницы документации Kotlin Coding Conventions от JetBrains.
Качество кода
Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.
В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.
Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.
Prettier в крупных проектах: тратим 20 минут на настройку, забываем о форматировании навсегда
Год назад одна из команд в Skyeng сталкивалась с такими холиварами почти на каждом ревью. Но затем человек, у которого больше всех болело, сказал: «Теперь живем на Prettier'e, согласны?» За следующие месяцы ребята ни разу не поднимали вопрос о форматировании, а теперь эта штука стоит на всем монорепозитории фронтенда — и его использует каждая команда, которая туда заезжает.
Prettier is a Must-Have for Large-Scale Projects: Spent 20 Minutes Setting It Up and Forgot About Formatting for a Year
It was an everyday reality for one of Skyeng dev teams a year ago. Then someone had enough and said, “Guys, from now on we use Prettier. Is everyone ok with that?” And then there were no more debates about formatting. We’ve installed Prettier in the frontend repo and all the teams use it.
Новый взгляд на code style
Как знания нейропсихологии могут помочь программисту в стилизации кода? До того, как заняться программированием, я очень долго и глубоко изучал нейропсихологию. Впоследствии эти знания помогли мне добиться высоких результатов в разработке за короткий промежуток времени.
В этой статье я хочу поделиться своим опытом и подходом к стилизации кода. Мы рассмотрим стилизацию со стороны программирования, а затем немного коснемся нейропсихологии для более глубокого понимания самого процесса и степени его важности для разработчика. Последний год я работаю в компании Secreate, где занимаюсь разработкой мобильных приложений на фреймворке React Native, поэтому примеры кода, приведенные в этой статье, будут на языке Javascript. Знания, полученные из этой статьи, можно будет легко применить к любому языку программирования. В конце статьи вас ждут полезные примеры стилизации кода. Приятного чтения!
Что такое стилизация
Каждый программист имеет свое представление о code style. Для меня стилизация — это набор правил для оформления, таких как: отступы, пробелы, переносы, последовательность и так далее. Тем не менее, каждый программист оформляет свой код по-своему. Давайте рассмотрим несколько примеров такого оформления.
Импорты
Некоторые программисты пишут их так:
import {SomeClass} from ‘some/file’
Некоторые так:
import { SomeClass } from ‘some/file’
Еще можно встретить такое:
import {SomeClass, someFunction, someConst, AnotherClass и еще много чего в длинную строку} from ‘some/file’
Или такое:
import {
SomeClass,
somefunction,
someConst,
AnotherClass,
и еще много чего в столбик
} from ‘some/file’
Объявление функций
CI, кодстайл и TDD: обзор практик для повышения качества кода
Blade Runner 2049, Warner Bros. Pictures
Я видел не во сне, а наяву атакующие корабли, пылающие под четырьмя вложенными if-else, и лучи CI с кучей сканирований у ворот Тангейзера, вызывающие лютую боль разработчиков. Меня зовут Максим Морев, и я техлид в Газпромбанке.
То, что вы сейчас увидите, выросло из внутреннего стайлгайда, к которому мы пришли через тернии многочисленных код-ревью и разработанных сервисов. Я постарался собрать здесь все основные и просто интересные грабли, которые нам попадались, и показать решения с примерами и обзором возможных трудностей в процессе внедрения.
Самый быстрый форматер кода
Самый быстрый форматер кода
В статье подробно поговорим о самом быстром форматере кода. Подробно покажем, как интегрировать форматер в любой проект, настроим форматирование по сохранению в редакторах кода и посоревнуемся в скорости форматирования.
Опыт разработки плагина для Yasca
Затерянный остров хорошего кода
Stack Exchange's "codereview" site is the new hotness for this sort of question.
Оказывается, больше года назад в застенках Area 51 был рожден вопросник Code Review, призванный делать код лучше.
Борьба за кодстайл или Bracket Wars
Для JavaScript'а, который долгое время оставался «за бортом» большой разработки, настала золотая эра быстрого развития и появления все новых и новых технологий на его основе, а приложения становятся все комплекснее с каждым днем. Учитывая, что принятие ежегодных стандартов, появление нового синтаксического сахара и «плюшек» делают его очень привлекательным для большего числа разработчиков, данная тема будет актуальна не один год. Новички в JavaScript с энтузиазмом берутся за его изучение, пробуя все новые и новые фишки, однако в большинстве своем они забывают об оформлении кода и о такой вещи, как технический долг.
Создаём библиотеку по последнему слову техники
Привет, Хабр. Это статья о том как написать Hello world по последнему слову техники.
В конце мы получим hello world библиотеку которая:
- Использует typescript
- Заботится о codestyle
- Генерирует доку
- Проводит тесты
Code style как стандарт разработки
Интересно? Добро пожаловать под кат.
Go: передача значений VS передача указателей
Go - один из немногих языков, в которых структуры можно передавать параметрами и возвращать из функций как по значению, так и по указателю. Это приводит к большей выразительности языка, но также разделяет общество разработчиков Go на два лагеря: сторонников указателей и сторонников значений.
В данной статье предлагается во многом субъективное сравнение обоих способов и делается попытка убедить читателей передавать и возвращать значения в тех случаях, где это возможно.
Молниеносный инкрементальный линтинг Python-кода
Линтинг кода бывает очень долгим, а в ситуациях наличия большого legacy‑проекта, который решили «причесать», линтинг может причинять боль и страдания разработчикам. В этой статье мы найдем решение, которое позволит без проблем линтить код с любого этапа разработки и делать это супер быстро и инкрементально!
C#. Сортировка членов типа с помощью ReSharper
Существуют некоторые соглашения касаемые структуры класса, и того, в каком порядке должны располагаться его члены.
Вот, например, правила которые использует StyleCop, возможно, в вашей компании есть свои собственные.
Поддерживать структуру вручную довольно тяжело, скучно и отнимает много времени, особенно когда в классе довольно большое количество свойств, полей, методов и.т.д.
В этом посте речь пойдет о том, как с помощью ReSharper автоматизировать этот процесс.
JSCS: JavaScript Code Style
История этого проекта началась с моей личной боли.
Незадолго до этого момента я перевёлся из одной команды Яндекс.Карт в другую и постепенно вливался в разработку нового для меня продукта. Все было хорошо, новый проект мне нравился, но кодстайл, в котором писали ребята из моей новой команды, очень уж сильно отличался от того стиля кодирования, в котором писал я и ребята из моей прежней команды. Однажды меня даже посетила нелепая мысль, что кодстайл в этой группе писался в противоположность кодстайлу в прежней группе специально, чтобы запутать меня.
Java: улучшаем качество кода (предусловия, IDEA QAPlug, интерграция GitHub c Codacy)
Продолжаю серию публикаций по учебному Java Enterprise проекту Topjava (Maven/Spring/Security/JPA(Hibernate)/Rest(Jackson)/ Bootstrap(CSS)/ jQuery+plugin).
Небольшая тема четвертого занятия: улучшаем качество кода
Полезные ссылки:
Удобная вставка многострочных шаблонных литералов в код на JavaScript
Описание проблемы
Появившиеся в ES6 шаблонные литералы (или шаблонные строки — template literals, template strings) помимо долгожданной интерполяции переменных и выражений принесли возможность вставки многострочного текста без дополнительных ухищрений, усложняющих вид кода.
Однако то, что красиво смотрится в разнообразных примерах на эту тему, в реальном коде порой облекается в новый вид безобразия.
Впрочем, проблемы видны, даже если присмотреться к примерам. Возьмём замечательную статью об этом нововведении из известной серии «ES6 In Depth».
Видите досадные «оспинки»? Лёгкие перекосы в симметрии и стройности?
var text = (
`foo
bar
baz`)
var html = `<article>
<header>
<h1>${title}</h1>
</header>
<section>
<div>${teaser}</div>
<div>${body}</div>
</section>
<footer>
<ul>
${tags.map(tag => `<li>${tag}</li>`).join('\n ')}
</ul>
</footer>
</article>`
Возьмём какой-нибудь простой случай и посмотрим на проблемы внимательнее.
ES5 руководство по JavaScript
JavaScript quality guide
С помощью советов предложенных в данном руководстве вы будете писать код, понятный любой команде разработчиков.
От переводчика
Всем привет, с вами Максим Иванов, и сегодня мы поговорим о правилах оформления кода на языке JavaScript. Николя Бэвакуа (Nicolás Bevacqua), автор книги «Дизайн JavaScript-приложений» (JavaScript Application Design), разработчик из Аргентины, опубликовал данное руководство достаточно давно, первая запись появилась еще в 2014 году, многое написано по стандарту ES5, однако, в наши дни это все равно актуально, сейчас, когда ES6 еще нигде полноценно не работает без babel и прочих транспайлеров. Хотя мы видим прогресс в топовых десктопных браузерах (Google Crhome, Firefox), где уже реализовано 70-90% задуманного, мы видим, что они стремятся поддерживать новый стандарт, но, к сожалению, ещё нет браузеров, которые полностью могли бы поддерживать ES6. К слову, я буду очень рад вашим комментариям. В общем, удачи и давайте начнем.
Не пишите код на 45-й строке
Это перевод статьи блоггера Brian McKenna. Разрешение на перевод получено.
Прямо сейчас в сообществе DynamoDB собираются мнения. Должны ли вы писать код на 45-й строке или нет. Я твёрдо убеждён, что 45-я строка должна быть оставлена пустой. И вот почему.
45-я строка ниже края экрана
По умолчанию высота терминала — 24 строки. Если писать код на 45-й строке, то программисты не сразу заметят его. Если оставить 45-ю строку пустой, то программист ничего не пропустит. Код чаще читается, чем пишется, поэтому убедитесь, что он виден.