Comments 27
Сделайте пожалуйста спойлер. Зачем всю статью на главной держать ;)
По-моему, всю статью можно сократить примерно до «Code style = добро; для JavaScript нужно использовать ESLint; у него есть плагины для Sublime Text, Atom, WebStorm» без особенной потери смысла.
Отдельно забавно, что в статье, пропагандирующей правильное количество пробелов в отступах, такой лютый ад с этими самыми отступами в примерах конфигов.
Отдельно забавно, что в статье, пропагандирующей правильное количество пробелов в отступах, такой лютый ад с этими самыми отступами в примерах конфигов.
Поправили, ишью переноса между реальным конфигом и доками/хабром
Ну, я считаю, что лишнее напоминание о хороших практиках не бывает лишним. Повторение — мать учения.
Лично наблюдаю товарищей, занимающихся фронтенд-разработкой (у себя на работе): мало у кого есть понимание о вещах упомянутых в статье, хотя многие не первый год работают. То есть конечно да, они слышали об этом, читали, м.б. пробовали, но… руки всё не доходят…
А вода камень точит: после сто первой статьи на хабре, глядишь: и пересилят себя, настроят линты наконец-то.
Лично наблюдаю товарищей, занимающихся фронтенд-разработкой (у себя на работе): мало у кого есть понимание о вещах упомянутых в статье, хотя многие не первый год работают. То есть конечно да, они слышали об этом, читали, м.б. пробовали, но… руки всё не доходят…
А вода камень точит: после сто первой статьи на хабре, глядишь: и пересилят себя, настроят линты наконец-то.
Сделано) спасибо
Используем standardjs — логичный и удобный, хорошо встраивается
Не могу обнаружить в статье описание, что делать с массивнейшими изменениями в системах контроля версий, ежели каждый разработчик будет переформатировать текст при сохранении.
Как решаете?
Как решаете?
Самое массивное с чем я сталкивался — это изменение окончания строк во всем файле. это выглядит стремно и я обычно такое возвращаю обратно и помогаю перенастроить гит(как правило это он), на сохранение текущих концов строк.
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.
Вы про всякие line-endings? Это можно автоматически настроить per-project в
Если дело не в VCS, то на помощь приходит
.git/config. Достаточно проапдейтить этот файлик в, например, npm-хуке postinstall.Если дело не в VCS, то на помощь приходит
.editorconfig, благо он поддерживается большинством редакторов/IDE.Я про то, что скобки могут скакать между строчками весьма значительно, появляться и исчезать:
http://astyle.sourceforge.net/astyle.html#_Bracket_Style_Options
http://astyle.sourceforge.net/astyle.html#_break-closing-brackets
http://astyle.sourceforge.net/astyle.html#_add-brackets
Более того, разница в стилях может быть такова, что существенно изменятся практически все строки.
Я думал, что вы ограничитесь форматированием на лету на вкус программиста, но вопрос сохранения в корпоративном формате остался не раскрыт. Раскрыт только вопрос о том, что программист может отображаемый стиль именно что сохранить в файл. Далее, естественно, идёт commit/push, и контроль версий красит красным почти полный файл. Если над модулем работают разные программисты — эти 90% изменения будут почти каждый коммит.
Сравните сами:
мои опции этого бьютифаера --style=bsd --add-brackets --add-one-line-brackets
ваши могут быть, например, --style=google --remove-brackets
И это далеко не line endings, и не только line-endings. Это ещё и "} while", «else if» и другие споры.
На мой взгляд было бы логично, если бы контроль версий включал в себя «корпоративное» форматирование перед пушем в репозитарий. Да то останутся описанные вами проблемы чтения при визуальном сравнении версий именно в репозитарии.
Потому и спрашиваю.
http://astyle.sourceforge.net/astyle.html#_Bracket_Style_Options
http://astyle.sourceforge.net/astyle.html#_break-closing-brackets
http://astyle.sourceforge.net/astyle.html#_add-brackets
Более того, разница в стилях может быть такова, что существенно изменятся практически все строки.
Я думал, что вы ограничитесь форматированием на лету на вкус программиста, но вопрос сохранения в корпоративном формате остался не раскрыт. Раскрыт только вопрос о том, что программист может отображаемый стиль именно что сохранить в файл. Далее, естественно, идёт commit/push, и контроль версий красит красным почти полный файл. Если над модулем работают разные программисты — эти 90% изменения будут почти каждый коммит.
Сравните сами:
мои опции этого бьютифаера --style=bsd --add-brackets --add-one-line-brackets
ваши могут быть, например, --style=google --remove-brackets
И это далеко не line endings, и не только line-endings. Это ещё и "} while", «else if» и другие споры.
На мой взгляд было бы логично, если бы контроль версий включал в себя «корпоративное» форматирование перед пушем в репозитарий. Да то останутся описанные вами проблемы чтения при визуальном сравнении версий именно в репозитарии.
Потому и спрашиваю.
Если я вас правильно понял, то требуется автоматическое приведение к некому стилю при коммите/пуше прозрачно для разработчика? (чтобы он мог работать со своими настройками)
Тогда можно установить гитхуки для автоформатирования опять же на этапе postinstall. Но мне такой вариант не кажется надежным, мало ли что там «наавтоформатируется» перед коммитом.
Другое дело, если IDE/редактор обязывает разработчика соблюдать определенный кодстайл.
Тогда можно установить гитхуки для автоформатирования опять же на этапе postinstall. Но мне такой вариант не кажется надежным, мало ли что там «наавтоформатируется» перед коммитом.
Другое дело, если IDE/редактор обязывает разработчика соблюдать определенный кодстайл.
Поняли правильно.
С гитхуками понятно. У AStyle «опасные ключи», которые удаляют-добавляют не только white-chars, можно не пользовать.
Осталось два мелких вопроса:
1) Как и где программист после пулл-реквеста может сравнивать версии в приятном глазу формате
2) Почему автор темы не упоминает эти вопросы ;-)
С гитхуками понятно. У AStyle «опасные ключи», которые удаляют-добавляют не только white-chars, можно не пользовать.
Осталось два мелких вопроса:
1) Как и где программист после пулл-реквеста может сравнивать версии в приятном глазу формате
2) Почему автор темы не упоминает эти вопросы ;-)
Смотрите какая идея во всем этом — не подстраиваться под «хочу — пишу, хочу — нет» конкретного человека, а форматировать исходный код всегда до коммита, чтобы разработчик всегда видел отклонения, всегда видел принятый кодстайл. Настойка оформления кода и сам кодстайл вынесен за рамки ответственности программиста и присутствует независимо от его предпочтений.В конечном итоге программист будет следовать ему со временем. Плюс ко всему — например я провожу ревью через гитлаб. Если код который я вижу в гитлабе, отформатирован так же как в редакторе или IDE, с которым я работаю — мне нужно лишний раз настраиваться на чтение(об этом я писал в статье).
Мы в команде при работе с WebStorm/Idea пришли к следующему:
eslint ставится в каждый проект, конфиги для него вынесены в отдельный репозиторий, который также подключается в каждый проект
в шторме включен eslint с конфигом, лежащим в node_modules, и в репозиторий закоммичена директория .idea/jsLinters. Это позволяет автоматически включать линтер в шторме на каждой машине (естественно, нужно сначала выполнить npm i)
в каждом проекте лежит .editorconfig с настройками отступов и прочего
Есть одна тонкость, шторм при указании конфига внутри проекта, почему-то не может автоматически подставить $PROJECT_DIR$ в путь, так что это нужно сделать руками в .idea/jsLinters/eslint.xml
eslint ставится в каждый проект, конфиги для него вынесены в отдельный репозиторий, который также подключается в каждый проект
в шторме включен eslint с конфигом, лежащим в node_modules, и в репозиторий закоммичена директория .idea/jsLinters. Это позволяет автоматически включать линтер в шторме на каждой машине (естественно, нужно сначала выполнить npm i)
в каждом проекте лежит .editorconfig с настройками отступов и прочего
Есть одна тонкость, шторм при указании конфига внутри проекта, почему-то не может автоматически подставить $PROJECT_DIR$ в путь, так что это нужно сделать руками в .idea/jsLinters/eslint.xml
Что с кодстайлом на данный момент? Все плохо: качество кода страдает в угоду скорости разработки
Оформив весь код по единым правилам вы не повысите его качество.
Пример, низкокачественного кода из реального проекта, реализованного по всем "best practice":
function Model() {
var data = {};
function getData() {
return data;
}
function setData(val) {
data = val;
}
Object.defineProperty(this, 'data', { get: getData, set: setData });
}Мозг человека — штука ленивая, он формирует некий инлайн кэш для чтения исходного кода, и как результат переключение между разными по стилю кусками или файлами требует времени для формирования новых паттернов чтения. Как по вашему, будет здорово, если разработчик при переходе с файла на файл будет «подвисать», формируя новую модель чтения? Вряд ли.
Мозг так не работает. Он быстро обучается замечать важное и игнорировать несущественное. Так что научившись один раз игнорировать оформление, вы сможете работать с любыми проектами, а не "подвисать" при переключении.
Оформив весь код по единым правилам вы не повысите его качество.
Я писал, что единое оформление освобождает ресурсы разработчика и дает возможность замечать плохой код. И при ревью, и при разработке. Если такой код попадает в продакшн — очень жаль того, кто это пропустил/написал. Все же код нужно читать, а не просматривать.
Мозг так не работает. Он быстро обучается замечать важное и игнорировать несущественное.
К сожалению, действительность далека от желаний. На моем опыте ряд проектов, которые требовали погружения и понимания, и отсутствие оформления кода затягивало процесс разработки. Возможно, мы рассуждаем о проектах разной сложности. Если проект не сложный — согласен, игнорировать можно
Только если вы привыкли читать лишь код лишь в одном стиле. Привыкайте читать код независимо от стиля и у вас не будет проблем. Поработайте одновременно в нескольких проектах с разными стилями и быстро научитесь замечать главное, а не акцентировать внимание на расположении пробелов.
Это философия, на мой взгляд. Кто-то любит чистоту и порядок, а кому-то плевать. Но тех кому плевать — обычно мало. Опять же, те, кто любит чистоту, делятся на тех, кто будет ее наводить, и на тех, которые терпеть не могут убирать. Первые берут веник, вторые — покупают робот-пылесос. Если вам плевать, с чем работать — то можете хоть минифицированный код писать;) В конечном итоге любой код должен быть человекочитабельным и однородным. По моему, оправдывать неряшливость отрешенностью — ну не ок. Но если вы познали дзен — ждем статьи о том, как не беспокоится об оформлении кода и как этого достичь)
Использую standartjs.com — просто и удобно
Если я верно понял — Standard — 3й в списке пресетов. Набрать 2 команды и выбрать Standard в списке из 3х пунктов — не сложно. ESLint более универсален, он модульный, настраиваемый и мощный. Если вам нужна поддержка разного кодстайла в разных проектах — он нужен. Если у вас 1 стиль для всего — можно конечно же ограничится 1 библиотекой
Он почти всем хорош, кроме очень спорного пункта с отказом от ";"
Выскажу одно мнение в качестве вброса.
У каждого свое чувство вкуса, и мнение как должен выглядеть код. Одно из решений, это инструменты автоматического форматирования кода.
На каждой машине, включая машину с репозиториями, ставится такой инструмент, который конфигурируется каждым разработчиком под себя, а на сервере конфигурируется мейнтейнером конкретного проекта под стайл гайд проекта, или какой-то дефолтный стиль.
В итоге, каждый пишет как ему нравится (визуально), но на сервере всегда лежит корректно отформатированая версия. Форматирование производится на клиентских машинах перед коммитом или пушем одной командой в консоли, а на сервере после мержа изменений в девелоп ветку. Никакой валидации по стайлгайду (пробелы, казюбрики) на клиенте, за исключением архитектурных правил.
Такого инструмента, насколько я знаю, год назад небыло, но вполне вероятно, что на базе ESLint его можно запилить.
У каждого свое чувство вкуса, и мнение как должен выглядеть код. Одно из решений, это инструменты автоматического форматирования кода.
На каждой машине, включая машину с репозиториями, ставится такой инструмент, который конфигурируется каждым разработчиком под себя, а на сервере конфигурируется мейнтейнером конкретного проекта под стайл гайд проекта, или какой-то дефолтный стиль.
В итоге, каждый пишет как ему нравится (визуально), но на сервере всегда лежит корректно отформатированая версия. Форматирование производится на клиентских машинах перед коммитом или пушем одной командой в консоли, а на сервере после мержа изменений в девелоп ветку. Никакой валидации по стайлгайду (пробелы, казюбрики) на клиенте, за исключением архитектурных правил.
Такого инструмента, насколько я знаю, год назад небыло, но вполне вероятно, что на базе ESLint его можно запилить.
Один мой коллега тоже так говорит. Однако, он еще не создал такого монстра, и вряд ли создаст.
Тут есть определенные проблемы, которые можно перечислять довольно долго. Одна из них заключается в том, что разработчики перестанут понимать друг друга. Смотрю я ревью, например, с хорошо отформатированным кодом, и говорю, строки с 130 — 140 — такие-то проблемы. Разработчик смотрит в свой код, а у него 100 строк в этом файле. Или еще кейс: просит меня разработчик помочь ему разобраться в моем коде — смотрит в мой монитор и говорит: а у тебя все не так, я ему говорю: пойдем посмотрим у тебя, раз не так. смотрю в его файл и тоже ничего не понимаю, потому что у парня помимо всяких своих прихотей по настройке внешнего вида ide, длина строк 55 символов вместо 120, к примеру. Ну это из самого безобидного)
Соответсвенно постоянно надо мапать 1 стиль на другой, разводить зоопарк из стилей. По моему личному убеждению — поддержка единого кодстайла на 1 проекте — вещь необходимая и обсуждению не подлежит. У всех разработчиков свой бекграунд, кто-то пришел из руби, кто-то из пхп, кто-то вообще пишет под настроение… если каждый будет вносить бедлам в проект — в команде будет много холиваров. Это не конструктивно и вредит разработке. Это долгий диспут, я считаю.
В общем, да это есть идея, но она крайне сырая и мы вряд ли можем ожидать ее воплощения в ближайшие годы. Ну и опять же, если не указывать разработчику, что его кодстайл далек от идеала, он не станет интересоваться бестпрактисами, оптимизацией выполнения и прочим.
Тут есть определенные проблемы, которые можно перечислять довольно долго. Одна из них заключается в том, что разработчики перестанут понимать друг друга. Смотрю я ревью, например, с хорошо отформатированным кодом, и говорю, строки с 130 — 140 — такие-то проблемы. Разработчик смотрит в свой код, а у него 100 строк в этом файле. Или еще кейс: просит меня разработчик помочь ему разобраться в моем коде — смотрит в мой монитор и говорит: а у тебя все не так, я ему говорю: пойдем посмотрим у тебя, раз не так. смотрю в его файл и тоже ничего не понимаю, потому что у парня помимо всяких своих прихотей по настройке внешнего вида ide, длина строк 55 символов вместо 120, к примеру. Ну это из самого безобидного)
Соответсвенно постоянно надо мапать 1 стиль на другой, разводить зоопарк из стилей. По моему личному убеждению — поддержка единого кодстайла на 1 проекте — вещь необходимая и обсуждению не подлежит. У всех разработчиков свой бекграунд, кто-то пришел из руби, кто-то из пхп, кто-то вообще пишет под настроение… если каждый будет вносить бедлам в проект — в команде будет много холиваров. Это не конструктивно и вредит разработке. Это долгий диспут, я считаю.
В общем, да это есть идея, но она крайне сырая и мы вряд ли можем ожидать ее воплощения в ближайшие годы. Ну и опять же, если не указывать разработчику, что его кодстайл далек от идеала, он не станет интересоваться бестпрактисами, оптимизацией выполнения и прочим.
Sign up to leave a comment.
Борьба за кодстайл или Bracket Wars