Многие уже приняли за норму форматирование кода разными тулзами (black) и сортировку импортов в алфавитном порядке с разбиением на группы (isort).

А что если начать сортировать ещё и весь остальной исходный код?

https://github.com/bwhmather/ssort

ssort сортирует функции и классы, ставя их после того, от чего они зависят. Получается, что вверху файла находятся самые низкоуровневые функции, от которых всё зависит, а внизу файла — самый главный высокоуровневый код. Прям как завещал дядюшка Боб.

> Makes old fashioned code navigation easier, you can always scroll up to see where something is defined, and reduces bikeshedding.

#formatter #tool

Ещё одна новость про форматирование.

Одна из популярных причин, почему люди не в восторге от идеи внедрить форматтер кода в свои старые проекты — это замусоривание истории изменений. Появляется царь-коммит, который изменяет весь код сразу, и git blame бессилен пробиться через него к более старым изменениям. Получается, с точки зрения Git, человек, запустивший Black, становится автором всего проекта 😅

Начиная с версии 2.23.0 (это 2019 год) Git поддерживает возможность игнорировать некоторые коммиты в git blame, что как раз и решает эту проблему.

Крутая новость в том, что GitHub теперь тоже в своём Blame View научился игнорировать такие коммиты. Создаёте специальный файлик, записываете туда хэши своих коммитов с форматированием кода и вуаля!

https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

#formatter #github #git #blame #black

Если вдруг кому нужна такая же фича в локальном консольном Git или в GUI, типа PyCharm или VSCode, то вот как это делается:

git config --local blame.ignoreRevsFile .git-blame-ignore-revs

Нужно выполнить после клонирования репозитория. К сожалению, самостоятельно Git находить этот файл пока что не научился.

#formatter #git #blame #black

Оказывается, крайний релиз форматтера black 22.1.0 (он же первый не-бета релиз) для всех основных платформ распространяется в виде колёс со скомпилированным нативным кодом. То есть там уже не обычный интерпретируемый питон, а именно нативный код, использующий Python API. На фоне долгожданной стабилизации форматтера эта новость осталась практически незамеченной.

Получается такое через компилятор mypyc, идущий в комплекте с тайп-чекером mypy. Он умеет транспилировать обычный код на питоне с тайп-аннотациями в исходники на C, а их уже можно скомпилировать в библиотеки для большинства платформ.

В итоге после компиляции и некоторых оптимизаций получилось ускорить работу форматтера в два раза. Время запуска тоже слегка сократилось. Из-за особенностей компилятора тайп-аннотации тоже стали строже.

Автор этой инициативы написал серию постов (раз, два, три) про возникшие по пути сложности. Любопытно.

#black #formatter #mypy #mypyc

Команда форматтера black готовится к новому году обновлению дефолтного стиля. Они весь год собирали разные изменения/улучшения, но не включали их, чтобы лишний раз не тревожить код пользователей. И вот в начале 2023 года выйдет релиз, где всё это наконец вступит в силу. Готовьтесь, что после обновления black у вас изменится форматирование кода. Вероятно, это обновление лучше делать отдельно от других изменений, чтобы не заставлять ваших ревьюверов вычитывать смысловые изменения в коде вперемешку с изменениями в форматировании.

Список изменений можно почитать в блоге одного из разработчиков: https://ichard26.github.io/blog/2022/12/black-23.1a1/

#black #formatter

Если хотите попробовать новый стиль уже сейчас, то это приветствуется и делается через установку превью-версии:

python -m pip install black==23.1a1

На одном из рабочих проектов форматирование новой версией завершилось вот с таким результатом, то есть изменилось ~5% файлов:

274 files reformatted, 4738 files left unchanged.

Большая часть изменений — это вырезанная первая пустая строка в определениях функций и классов. Пожалуй, хорошо, что форматтер стал за этим следить, а то эти пустые строки воспринимались как что-то лишнее. Кто, блин, их вообще ставит?

Многие изменения я словить не смог, но они должны быть весьма приятными. Например, форматтер вместо разгибания тайп-хинта по какой-то произвольной скобке:

def frobnicate() -> ThisIsTrulyUnreasonablyExtremelyLongClassName | list[
    ThisIsTrulyUnreasonablyExtremelyLongClassName
]:
    pass

Научился группировать и делать более осмысленные переносы:

def frobnicate() -> (
ThisIsTrulyUnreasonablyExtremelyLongClassName
| list[ThisIsTrulyUnreasonablyExtremelyLongClassName]
):
pass

#black #formatter