DB
SwiftLint прежде всего линтер, исправляет человек 🌚
' vs "
Такое пугаетSize: a a a
2021 September 01
DB
Что именно? Второй комментарий как раз в точку — black про "делать работу и не думать про стиль"
S
Никогда не воспринимал форматтеры в таком ключе. Подумаю, спасибо :)
DB
Если хочется боли, то можно втащить flake-8 с кучкой плагинов (или сразу wemake-python-styleguide). Там можно относительно легко писать кастомные правила, запрещать всякое разное
DB
Мне кажется он жестит, и очевидно не спасает от плохого кода, иногда может дать плохой в конкретном случае совет, и бездумно его слушать не надо.
Но на большом временном промежутке очень заметна разница между проектом, где такой линтер включен и где нет — код задокументирован, нет "плохих" переменных, код разбит на функции, а функции на модули
Но на большом временном промежутке очень заметна разница между проектом, где такой линтер включен и где нет — код задокументирован, нет "плохих" переменных, код разбит на функции, а функции на модули
Б
Затащил недавно, набил шишек
Б
Это, плюс mypy/pyright, плюс black
Б
Затаскивать это всё очень больно
DB
DB
приходите работать в инфраструктурную команду: у нас новый проект каждый месяц 🌝
DB
можно не затаскивать, а начинать новый проект сразу красиво
Б
Короче, один совет который могу дать: если есть долгоживущие фича бранчи, не надо тащить black, пока они не будут вмержены. Ну либо выделить время чтобы сидеть и ребейзить это всё 🌚
Б
Я был к этому готов, и был план как это безболезненно сделать, но оказалось что из одной такой ветки много черрипикали в мастер, причём изменяя потом этот код, что породило кучу конфликтов и боли.
Но в итоге всё равно нашел способ не разрешать конфликты вручную.
Но в итоге всё равно нашел способ не разрешать конфликты вручную.
p
S
В плане?
Б
Ниже написал
PR
очень странная у вас инфраструктурная команда)
PR
это какая-то новая? Ибо в старой инфраструктурной команде были очень старые проекты
Б
А, ну и ещё исключить коммит с реформатом из git blame могу посоветовать