Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

SCSS, SASS, CSS code styles — best practices

Доброго дня.

Ми в компанії для розробки використовуєм ci flow github.com/propeoplemd/cibox із сканерами для коду і для файлів дизайну.
Із сканерами для коду наче все ок і в даному виді питань не виникає.
А от із сканерами для sass, scss — ціла епопея. Ймовірно через те, що я не фронтенд розробник і домовитись із ними досить важко.
Ми спробували використовувати scss-lint github.com/brigade/scss-lint для сканування, і csslint.net — але ну ніяк, повний ступор — не хочуть писати по стандартам. Приходиться з цим миритись.
Але все ж хочеться даних процес контролювати, бо якість коду, написаного фронтендами сильно страждає.

Буду вдячний за підказки, якого роду інструменти і техніки можна використати для покращення і уніфікації стандартів написаного коду фронтенд розробниками.

Ймовірно в когось є наявний набір правил-конфігурацій для scss-lint/css-lint , який показав себе з кращого боку — буду вдячний за «поділитись» досвідом і best-practices.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Берете линтеры под это дело. Потом хуки в гите настраиваете. Я например пользуюсь overcommit, который нужные линтеры и не только их запускает перед коммитом. Ну и зависимости от того как сильно их любите настраиваете когда будет просто ругаться ворнингом а когда фейлиться при попытке коммита кокашек.
Ну а если они не просто ленивые а ещё и хитрые то можно запретить пушить в рабочую ветку, а мержить в неё дать доступ например через веб интерфейс определённого лица. И так чтоб в перед мержем эти хуки с линтерами выполнялись

Питання в тому, які лінтери і як заставити розробників слідувати їхнім правилам?
Як їх приєднувати до workflow ми вже реалізували.

як заставити розробників слідувати їхнім правилам?
Ну и зависимости от того как сильно их любите настраиваете когда будет просто ругаться ворнингом а когда фейлиться при попытке коммита кокашек.

warnings не працюють. Всі тупо ігнорять.
Як тільки вмикаю fail — кількість помилок зашкальна — і адміністративно вимикаються назад (

Делаете прогон lint на git commit hook. Всё. Можно client-side, а можно server side.

Як тільки вмикаю fail — кількість помилок зашкальна

Неправильно делаете. Зафиксируйте количество фейлов и сделайте правило “запрещать коммит, если количество ошибок увеличилось”. Со временем, это количество можно уменьшать по ходу рефакторинга.

о, точно, дякую за ідею!

обычно план такой — брать конфиг по умолчанию и вычеркивать правила против которых есть несогласные (один-кворум-все — это уже решать коллективу или тимлиду/менеджеру/...)

Подписаться на комментарии