в в проекте везде разные отступы в vue файлах
не понимаю почему так... где 2 где 4 пробела, где-то табы
для фронта свои правила, для php свои отступы. поищите на гитхабе тот вариант, который ближе к вам. в разных ситуациях он может быть разный.
Ну да, слышал где-то что разные? А как вы на своих проектах делайте? У меня сейчас несколько людей, в коже и паха и жс Кто на шторме, кто на вскоде Хз как сделать просто и приятно всем , нагуглилсч вот едитооконфиг, ищу какие-то бестпрактис
composer global require dragon-code/codestyler И в папке с кодом: codestyle editor А фикс самого код-стайла можно так, если его вид устроит: codestyle А если нужен только файл, тогда https://github.com/TheDragonCode/codestyler/blob/main/.editorconfig
Офигеть какой огромный файл) Спасибо
Я себе для удобства полную схему экспортировал. Можно и частично, но тогда на разных компах по-разному может быть, а так все настройки берутся из файла. Все мои проекты этим код-стайлером поддерживаются.
Попробую завтра, а то в проекте везде по разному все, отформатировал файл штормом, а он все строки поправил, то отступы, то переносы и поэтому мерджреквест огромный и бесполезный становится
Когда у каждого разработчика свой конфиг в шторме, такие проблемы будут всегда. У нас в проекте перекидывают xml файл с конфигом шторма т.к. довольно часто .editorconfig файлы не читаются, особенно на убунте. Хз как так, но народ жалуется постоянно. Под виндой и на маке таких проблем не замечено. А что касается код-стайлера, можно даже Laravel Pint взять хоть в дефолтной конфигурации (базируется на PSR-12), хоть на PER стандарт поставить (это следующая версия после PSR-12).
ни разу не сталкивался чтоб его не читало, он же по дефолту в репе есть. только что шторм отдает приоритет текущему код стайлу для старых файлов. т.е. надо форматирование применить, тогда он подсасывает из конфига
А есть какой-то способ пробежаться по файлам и применить, один первый раз
ctrl+shift+l вроде. посмотри в меню code - refactoring
Я тоже раньше не сталкивался, но двое коллег постоянно жалуются. Либо целенаправленно саботируют его использование, к чему я больше склоняюсь. А ещё его нет в репе - он ставится код-стайлером при выполнении команды composer install.
https://github.com/laravel/laravel/blob/10.x/.editorconfig Или мы о разном?
Он не полный. Во-первых в нём нет правил в 4 пробела для файлов фронта, а во-вторых, всё что не определено в файле, будет читаться из самого шторма, а у каждого разраба свой конфиг может быть.
достаточный он. в 4 пробела? с каких это пор на фронте 4 пробела. двойка популярнее в чистом фронте, по причине большого количества коллбэков. у того же eslint-а, например, у плагинов вуя или накста, рекомендации 2 пробела. https://eslint.org/docs/latest/rules/indent https://www.reddit.com/r/typescript/comments/utpozn/poll_indent_width/ уточните конфиг для необходимого уровня. то что ты выше кидал вообще жесть, зачем там это всё нужно? просто чтобы было? у вас может это и надо было, но всем подряд такое рекомендовать не надо. это всё равно что гитигнор набить мусором всяким на все случаи жизни.
eslint руководствуется правилами настройки. Да, по-умолчанию там стоит 2 пробела. Да, это популярный размер. Но кто сказал что он удобен всем разработчикам без исключения? Лично у меня отступы в 2 пробела в кашу сливаются и я уже через несколько минут просто не вижу их ¯\_(ツ)_/¯ Как по мне, то отлично читается. Жесть - это в .editorconfig указывать десяток строк, которые, по сути, практически ничего не корректируют, т.к. остальные настройки будут взяты из шторма на том компе, где он запускается, а у каждого разраба эти настройки свои. Когда один над проектом работаешь, то это норм, но вот когда команда разрабов, тогда начинают случаться конфликты по код-стайлу, и в этом случае нужно покрыть максимум кейсов дабы не возвращаться к ним. Тот файл это всего-лишь экспорт текущего состояния конфига шторма, который я годами вылизывал до идеала. Зато, благодаря ему, я могу быть уверен что абсолютно любой человек с IDE, поддерживающей работу с EditorConfig, отформатирует код согласно этим правилам и нет необходимости его перепроверять. А что касается линтеров при запуске, это, конечно, хорошо, но вот если разрабы будут писать в разных стилях, затем запушат, там сработает линтер, они запушат ещё раз не дождавшись его завершения и получат конфликт. А это время и нервы на его решение. Поэтому конфиг файла на 100% повторяет конфиг линтера.
Здравствуйте, а почему почти у всех параметров ij приставка. я понимаю, что это подсказка для шторма. но ничего же страшного не будет если эту приставку удалить? в команде часть людей на шторе, а часть на вс_коде, едиторконфиг должен решать одну задачу - у всех одинаковое форматирование, отсюда и вопрос про приставку
Интересный вопрос. Не задумывался раньше. Да, приставка "ij" выглядит как "IntelliJ" - базовый софт на котором все сборки брейнсов работают. И, судя по всему, этот набор правил для шторма в том числе. Надо будет на досуге почитать про правила в VSCode и обновить файл для себя.
Я тоже попробую, но маякните плиз мне, если не сложно , что в итогу вас получится Я вечером попробую приставку удалить и поглядеть в обеих иде поведение
Не в приставке дело. Если VSC имеет те же ключи настройки, тогда да
Обсуждают сегодня