Freecodecamp: Создание руководства по стилю CSS от freeCodeCamp

Созданный на 8 янв. 2018  ·  47Комментарии  ·  Источник: freeCodeCamp/freeCodeCamp

Я хотел бы предложить руководство по стилю CSS от freeCodeCamp, чтобы улучшить общую ремонтопригодность кодовой базы. Поскольку у FreeCodeCamp много участников, и каждый пишет CSS по-своему. И трудно уследить за разными способами написания CSS.

Первоначальные рекомендации:

Комментарии

  • Добавляйте комментарии, когда вы запускаете новый файл LESS, чтобы разработчики знали, с чем они работают, также добавляйте комментарии при запуске нового раздела, который связан с блоком кода, это помогает с удобочитаемостью, см. ПРИМЕРЫ ниже (я столкнулся с этот стиль комментариев по всей базе кода, поэтому я хотел бы продолжить его писать, вместо того, чтобы предлагать новый стиль)

  • Пример 1 - при запуске нового файла LESS:

//
// Navigation
// --------------------
  • Пример 2 - при добавлении раздела, связанного с навигацией
//
// Navigation - Mobile Styles
// ------------------------------

Расстояния

  • Добавьте пробелы после свойства, так будет намного проще читать такую ​​кодовую базу и поддерживать ее. См. ПРИМЕРЫ ниже.

  • Пример 1 - правильный путь

p {
  color: #fff;
}
  • Пример 2 - Неправильный способ
  • Что случилось?
    Нет пробела после двоеточия
p {
  color:#fff;
}

Цвета

  • Предпочитайте строчные буквы, а не прописные. Теперь участники смешивают и то, и другое в CSS. Строчные буквы пишутся быстрее, их легче читать. Опять же, улучшает общую ремонтопригодность, если CSS имеет согласованное соглашение. Также, если возможно, сократите шестнадцатеричное значение. См. ПРИМЕРЫ ниже.

  • Пример 1 - правильный путь

p {
  color: #fff;
}
  • Пример 2 - Неправильный способ
  • Что случилось?
    шестнадцатеричное значение в верхнем регистре, не укороченное
p {
  color: #FFFFFF;
}

RGBA или RGB цвета

  • Добавляйте пробелы после значений, улучшает читаемость. См. ПРИМЕРЫ ниже:

  • ПРИМЕР 1 - Правильный способ

p {
  color: rgba(123, 123, 0, 0.1);
}
  • ПРИМЕР 2 - Неправильный способ
  • Что случилось?
    Без пробелов после значений
p {
  color: rgba(123,123,0,0.1);
}

Нет единицы при объявлении 0

  • В таком свойстве, как box-shadow, если вы устанавливаете значение 0, вам следует избегать добавления единицы. См. ПРИМЕР ниже.

  • ПРИМЕР 1 - Правильный способ

p {
  box-shadow: 1px 1px 0 rgb(0, 0, 0);
}
  • ПРИМЕР 2 - Неправильный способ
  • Что случилось?
    Единицы после 0
p {
  box-shadow: 1px 1px 0px rgb(0, 0, 0);
}

Избегайте плавающих чисел

  • Если возможно, вам следует избегать плавающих чисел в CSS для разных размеров, так как они могут отображаться немного иначе. См. Ссылку ниже.

Округление браузера

help wanted docs on the roadmap

Самый полезный комментарий

@raisedadead @tomasvn По соблюдение в долгосрочной перспективе не принесет полезных результатов. React, Yarn, Babel и многие другие проекты с открытым исходным кодом используют Prettier и другие подобные расширения для форматирования стилей CSS.

Вместо создания руководства по стилю. Мы должны сказать нашим участникам, чтобы они установили Prettier в их редакторе IDE / кода, и мы будем в порядке.
@raisedadead Мысли по этому

Все 47 Комментарий

@raisedadead Что ты думаешь?

Спасибо, вы знаете, как это можно сделать? Используете какой-нибудь линтер?

@raisedadead @tomasvn По соблюдение в долгосрочной перспективе не принесет полезных результатов. React, Yarn, Babel и многие другие проекты с открытым исходным кодом используют Prettier и другие подобные расширения для форматирования стилей CSS.

Вместо создания руководства по стилю. Мы должны сказать нашим участникам, чтобы они установили Prettier в их редакторе IDE / кода, и мы будем в порядке.
@raisedadead Мысли по этому

Спасибо, вы знаете, как это можно сделать? Используете какой-нибудь линтер?

Похорошее работает;). Он предупреждает вас, когда вы нарушаете какое-либо правило стиля CSS.

Вместо создания руководства по стилю. Мы должны сказать нашим участникам, чтобы они установили Prettier в их редакторе IDE / кода, и мы будем в порядке.

Скрытие от проблем никому не помогало ... 😅!

Я категорически за то, чтобы избегать форматеров и использовать вместо них линтеры. Автоматизация звучит круто и просто, но они убирают ключевой момент написания стандартного кода.

ИМХО, мы, как сообщество, занимающееся обучением, не должны уклоняться от исправления проблем в стиле кода, указанном линтерами.

Также обратите внимание, что Prettier - это _Opinionated_ Code Formatter.

По моему мнению, процесс создания руководства по стилю CSS и его соблюдение в долгосрочной перспективе не принесет полезных результатов.

Я думаю, это неверный аргумент (не стесняйтесь доказывать мою неправоту, если у вас есть статистика).

Если вы посмотрите руководство по стилю Airbnb JS, стандарт JS и т. Д., У них есть помощник для написания стандартного кода, и они используются тысячами компаний и разработчиков каждый день.

@raisedadead Мы не прячемся от проблем ...! Мы можем использовать линтеры, но ту же задачу можно выполнить с помощью привязки одного ключа с Prettier, так почему мы пытаемся над этим долго работать?

Я думаю, это неверный аргумент (не стесняйтесь доказывать мою неправоту, если у вас есть статистика).
Если вы посмотрите руководство по стилю Airbnb JS, стандарт JS и т. Д., У них есть помощник для написания стандартного кода, и они используются тысячами компаний и разработчиков каждый день.

Я полностью с вами согласен! Их руководства по стилю JS действительно очень полезны.

Мы не прячемся от проблем ...! Мы можем использовать линтеры, но ту же задачу можно выполнить с помощью привязки одного ключа с Prettier, так почему мы пытаемся над этим долго работать?

Потому что мы хотим писать стандартный код? Авторы могут использовать любые инструменты, которые им нравятся, но это не означает, что нам не нужно руководство.

В любом случае, давайте оставим эту ветку для конструктивного отзыва о руководстве, вместо этого мы всегда можем обсудить это в чате.

@tomasvn RFC выглядит интересным, и, поскольку вы заинтересованы в обратной связи, думаете ли вы, что сможете найти некоторые устоявшиеся руководства по стилю и инструменты, на которые мы можем черпать вдохновение.

Потому что мы хотим писать стандартный код? Авторы могут использовать любые инструменты, которые им нравятся, но это не означает, что нам не нужно руководство.

Я тоже с тобой в этом. Хорошо, давайте возьмем руководство по стилю, и мы можем использовать stylelint в качестве

@raisedadead stylelint кажется прекрасным 👍 Поскольку он предупреждает автора о несоответствиях в его документе

@tomasvn Мы только что запустили нашу новую учебную программу и обучающую платформу. Вы все еще заинтересованы в этом?

Весь наш CSS нуждается в хорошем рефакторинге, и это будет хорошей возможностью не только создать руководство по стилю, но и сразу же применить его к проекту, а также убедиться, что все наши репозитории соответствуют ему.

@QuincyLarson Конечно, я могу потратить немного времени и помочь вам с рефакторингом CSS, так как freecodecamp - довольно большая кодовая база, просто укажите мне, с чего мне начать

@tomasvn Было бы

В freeCodeCamp не так уж много CSS. CSS freeCodeCamp в основном находится в main.less. И мы используем Bootstrap 3.0.

В конечном итоге мы можем перейти на Bootstrap 4.0 или просто переписать наш CSS для использования Flexbox. Но на данный момент мы используем React Bootstrap в нескольких наших приложениях, и в настоящее время он заблокирован для Bootstrap 3.0. Поэтому я рекомендую просто зайти и очистить существующий настраиваемый CSS в main.less, сделав его менее избыточным и более логичным.

@QuincyLarson получил его, а main.less находится в client / less / main.less, это правильный файл?

@tomasvn Спасибо за терпение - я только что это видел. Да - client / less / main.less должен быть правильным файлом.

@tomasvn Нужна помощь? Я буду рад внести свой вклад

@tomasvn у тебя уже была возможность начать работать над этим? Если нет, @borisyordanov Да, мы будем рады вашим взносам.

@borisyordanov извините за задержку, конечно, продолжайте У меня проблемы с запуском dev env в Windows, так что вы можете начать, когда я исправлю свои вещи, я могу помочь вам его реорганизовать

@tomasvn Я отправил вам электронное письмо, давайте встретимся в чате и с руководством, если вы еще этого не сделали, или попросить о помощи в Gitter.

Если есть необходимость, я могу помочь с этим

@ Jgriebel1990 Я не мог связаться с tomasvn, поэтому, насколько мне известно, никакого прогресса не произошло. Не стесняйтесь брать на себя

@ jgriebel1990 не стесняйтесь брать на себя

@tomasvn похоже, что у @ Jgriebel1990 и @borisyordanov не было возможности решить эту проблему - вы все еще заинтересованы в том, чтобы помочь с этим?

@QuincyLarson Я постараюсь заставить его работать в Windows, у меня все еще есть проблемы с его запуском. Если я не смогу настроить свою среду, просто закройте поток.

@tomasvn Не беспокойтесь - вам не удалось запустить его локально?

@QuincyLarson Не повезло, запустить его локально

@tomasvn с какими проблемами вы столкнулись при локальной настройке.

@raisedadead С обновлениями на https://github.com/freeCodeCamp/design-style-guide , нужна ли эта проблема?

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

Стиль границы CSS
Свойство border-style указывает, какую границу отображать.

Допускаются следующие значения:

dotted - определяет пунктирную границу
dashed - определяет пунктирную границу
solid - определяет сплошную границу
double - определяет двойную границу
Groove - определяет трехмерную рифленую границу. Эффект зависит от значения цвета границы.
гребень - определяет трехмерную гребенчатую границу. Эффект зависит от значения цвета границы.
вставка - определяет границу вставки 3D. Эффект зависит от значения цвета границы.
outset - определяет исходную трехмерную границу. Эффект зависит от значения цвета границы.
none - не определяет границы
hidden - определяет скрытую границу
Свойство стиля границы может иметь от одного до четырех значений (для верхней границы, правой границы, нижней границы и левой границы).

ПРИМЕР-
p.dotted {border-style: dotted;} p.dashed {border-style: dashed;} p.solid {border-style: solid;} p.double {border-style: double;} p.groove {border-style: groove;} p.ridge {border-style: ridge;} p.inset {border-style: inset;} p.outset {border-style: outset;} p.none {border-style: none;} p.hidden {border-style: hidden;} p.mix {border-style: dotted dashed solid double;}

Привет! Какой прогресс в этом? Я готов помочь!

@ManasMahanand , спасибо за
Было бы здорово, если бы вы могли заглянуть в доступные линтеры css, сравнить их и посмотреть, есть ли что-нибудь лучше stylelint.
Затем добавьте линтер в наше репо и измените файлы CSS, чтобы убедиться, что репо не содержит ошибок.

@madabdolsaheb Подойдет !

@ahmadabdolsaheb Подождите, что вы имеете в виду добавить в репо?

Вы хотите, чтобы я установил линтер как зависимость, например, eslint?

Или есть способ установить тесты на самом github, чтобы они не позволяли слияние, если не следовать руководству по стилю?

Хорошо, похоже, stylelint сам по себе хороший вариант. Я это устанавливаю.

Для экспериментов я установлю правила, предложенные OP. Затем я удалю все правила и открою PR. Затем мы можем обсудить и установить правила

https://stylelint.io/user-guide/rules/about

Вы можете посмотреть на эту ссылку, чтобы увидеть типы правил, которые можно установить

image

в настоящее время уже существует команда lint: css, которая использует prettier. Мы можем изменить его, чтобы использовать stylelint.

Как бы то ни было, я установил его, и он успешно обнаруживает ошибки на основе набора правил. Могу я открыть PR?

Нет необходимости удалять prettier, у prettier есть конфигурация для правил stylelint, которые вы можете использовать для расширения файла конфигурации prettier

Потрясающе. Будем работать над этим завтра.

Я не нашел более красивой конфигурации для правил stylelint (или как это сделать), но в настоящее время я установил еще один пакет stylelint-config-prettier, который будет проверять наличие конфликтов и отключать любые правила, которые конфликтуют.

Я думаю, что в команде lint: css мы также можем запустить команду stylelint вместе с prettier

(Мнение) Я считаю, что мы можем написать все собственные правила stylelint на основе того, что имеет смысл для fcc, и даже полностью удалить более красивое. Это просто мнение, решать вам, ребята.

Спасибо @ManasMahanand за ваш прогресс. Я помечу @ojeytonwilliams, чтобы

Я думаю, что prettier хорошо справляется с форматированием, поэтому я лучше оставлю это. Если мы используем https://github.com/prettier/stylelint-prettier, тогда prettier используется как плагин stylelint, и мы получаем лучшее из обоих миров.

Это отражает подход, который мы уже используем для линтинга JavaScript.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги