#линтеры — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #линтеры, aggregated by home.social.
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
ИИ бот-модератор 1: Начало проекта
Знаете, в чём проблема большинства гайдов и курсов, которые обещают научить всему и сразу — да ещё и устроить на работу? Часто они учат примитиву, выдавая это за качественный контент. В итоге появляется много низкокачественного кода: на первый взгляд он работает, но в реальности трудно поддерживается . Если в проекте нет структуры, он быстро превращается в кашу. Каждая доработка — это не отдельный продуманный модуль, а «приматывание новых кусков кода синей изолентой» с мыслью: «хоть бы не сломалось». Для новичка это особенно опасно: кажется, что всё нормально, пока проект маленький, но при росте даже простые изменения начинают занимать часы и ломать соседние части. Вы наверняка задаётесь вопросом: «Почему рубрика называется “ИИ бот-модератор”, а автор тут рассказывает про качество кода?» На самом деле, всё связано. Telegram-бот для группы — отличный пример проекта, который очень быстро обрастает фичами: команды, настройки, роли, интеграции, хранение данных, логирование, админка, модерация, ИИ и т.д. Если делать всё “в одном файле”, это почти гарантированно закончится болью. Поэтому в этой рубрике мы будем строить бота так, чтобы его можно было развивать: добавлять функциональность без постоянного страха «сломать всё».
https://habr.com/ru/articles/978282/
#telegram #бот #ии #git #make #precommit #линтеры #ruff #ry #uv
-
Форматирование без боли: ESLint Stylistic вместо Prettier
Привет, Хабр! Меня зовут Никита Ли, я Frontend-разработчик в группе Рунити. Так тяжело бывает удержаться от того, чтобы не усложнить себе жизнь, не так ли? Все любят смотреть на чистый и понятный код, но не все его таким пишут. Сделать его таким помогают наши друзья — форматировщики и линтеры. О них и пойдет речь в этой статье, а конкретно о ESLint Stylistic . Любой автор хочет, чтобы его кто-то читал, даже на JavaScript, но просматривать читателю хочется грамотный и красивый текст. ESLint анализирует код, выявляя ошибки, чтобы программы выходили из под клавиатуры чистыми и без ошибок. Prettier, в свою очередь, как инструмент форматирования делает текст исходного кода программ единообразным. Оба этих инструмента являются практически стандартом, когда речь заходит о качестве кода. Думаю, что многие сталкивались в проектах с их одновременным применением, что в целом логично — форматирование != линтинг. Однако это решение не всегда обосновано, а зачастую излишне. В качестве альтернативы я предлагаю рассмотреть ESLint Stylistic. В этой статье разберемся, что это, откуда появился инструмент и почему с ним стоит познакомиться.
https://habr.com/ru/companies/runity/articles/914920/
#eslint #prettier #линтеры #линтинг #форматирование_кода #frontend #javascript #качество_кода
-
В поисках хорошего стиля. Часть 1. Зачем нам свои линтеры на Go в Островке
Мы написали свои линтеры для Go, которые умеют находить пустые инициализации и проверять экспортируемость полей и методов типов. Сегодня мы поговорим о том, как наша команда пришла к собственному линтеру, и немного погрузимся в детали его реализации. Всем привет! Меня зовут Артём Блохин, я Golang-разработчик в команде интеграций Островка. Если бы «Рождественская история» Чарльза Диккенса была про стиль кода, то получилось бы как-то так: «Начнём сначала: код‑стайл умер. Сомневаться в этом не приходилось. Свидетельство о его погребении было подписано девопсом, архитектором и тимлидом. Оно было подписано разработчиком Островка.» Отправиться на поиски хорошего стиля
-
Жизнь без линтеров и расчет цены абстракции: материалы для разработчиков на С++
В марте мы собирались на митапе по С++ в Санкт-Петербурге. Для всех, кто не смог присоединиться к встрече, подготовили записи докладов и дискуссии с экспертами из YADRO, VK и Kaspersky, а также создателем Sprinx Андреем Аксёновым. Почему стоит сохранить подборку в закладки: • Руководитель отдела компиляторов научит рассчитывать цену абстракции для функций и других сущностей с учетом ваших ресурсов и возможностей компилятора. • Эксперт из PVS-Studio покажет, почему линтеры не всегда подходят для поиска ошибок и какое решение использовать вместо них, чтобы не навредить безопасности сервиса. • Инженеры с многолетним опытом работы на С++ поделятся опытом проведения код-ревью — возможно, вы найдете в их практиках что-то полезное или просто посмеетесь вместе с участниками дискуссии.
https://habr.com/ru/companies/yadro/articles/807145/
#абстракции #функции #c++ #корутины #линтеры #кодревью #дискуссия #ошибки_в_коде #митап
-
Как автоматизировать использование дизайн токенов с помощью Stylelint и PostCSS
Привет, Хабр! Меня зовут Саша и вот уже 7 лет я работаю фулстек разработчиком и пишу на C# и TypeScript/React. Сегодня я хотел бы поделиться своим небольшим успехом в автоматизации. В какой-то момент я понял, что во время код ревью я указываю разработчикам на одни и те же ошибки. Но, что ещё хуже, я сам время от времени допускаю эти ошибки. Сегодня хочу рассказать об одной из таких проблем, которую я решил с помощью PostCSS + Stylelint, и о том, как я это сделал. Статья будет полезна для разработчиков, которые уже используют или собираются использовать дизайн токены. Начнём!
https://habr.com/ru/articles/779492/
#javascript #stylelint #postcss #дизайнтокены #автоматизация #cssпеременные #линтеры #typescript #плагины