Interface Web

Guide de style Sass: un didacticiel Sass sur la façon d'écrire un meilleur code CSS

Écrire un CSS cohérent et lisible qui évoluera bien est un processus difficile. Surtout lorsque les feuilles de style deviennent plus volumineuses, plus complexes et plus difficiles à maintenir. Les préprocesseurs sont l'un des outils dont disposent les développeurs pour écrire de meilleurs CSS. Un préprocesseur est un programme qui prend un type de données et le convertit en un autre type de données, et dans notre cas, les préprocesseurs CSS sont des langages de prétraitement qui sont compilés en CSS. Il existe de nombreux préprocesseurs CSS qui développeurs front-end recommandent et utilisent, mais dans cet article, nous nous concentrerons sur Sass. Voyons quoi Sass a à offrir , pourquoi c'est un choix préférable par rapport aux autres préprocesseurs CSS, et comment commencer à l'utiliser de la meilleure façon.

Qu'est-ce que Sass et pourquoi devriez-vous l'utiliser?

Pour ceux d'entre vous qui ne savent pas ce qu'est Sass, le meilleur point de départ est de visiter le page Web officielle de Sass . Sass est un acronyme pour Syntactically Awesome StyleSheets, et est une extension de CSS qui ajoute puissance et élégance au langage de base.

Avec Sass (Syntactically Awesome StyleSheets), votre code CSS sera également génial.

Sass est un préprocesseur CSS avec de nombreuses fonctionnalités puissantes. Les caractéristiques les plus notables sont variables , étend , et mixins .

Les variables stockent des informations qui peuvent être réutilisées ultérieurement, comme les couleurs ou d'autres valeurs couramment utilisées. Extends vous aide à créer des «classes» qui permettent l'héritage des règles. Mixins, vous pouvez penser à une «fonction». Sass possède également d'autres fonctionnalités étonnantes par rapport à d'autres préprocesseurs, comme l'utilisation d'instructions logiques (conditionnelles et boucles), des fonctions personnalisées, l'intégration avec d'autres bibliothèques comme Le compas , et beaucoup plus. Ces fonctionnalités à elles seules peuvent vous aider, vous et votre équipe, à être plus productifs et à rédiger un meilleur CSS à la fin.

Pourquoi vous avez besoin d'un guide de style CSS

Malheureusement, même les préprocesseurs ne peuvent pas tout réparer et vous aider à écrire un bon code CSS. Le problème auquel tous les développeurs sont confrontés est que les applications Web actuelles deviennent de plus en plus grandes. C'est pourquoi le code doit être évolutif et lisible, et doit éviter code spaghetti et des lignes inutilisées de celui-ci. Pour éviter les problèmes mentionnés, une sorte de norme pour votre équipe dans le travail quotidien est nécessaire. Qu'est-ce que le code spaghetti et comment cela se passe-t-il? Le code spaghetti est un nom pour un code mauvais, lent, répétitif et illisible. Lorsqu'une équipe écrit de grosses applications sans directives ni normes définies, chaque développeur écrit ce dont il a besoin et comme il le souhaite. De plus, lorsque les développeurs écrivent de nombreux correctifs de bogues, correctifs et correctifs, ils ont tendance à écrire du code qui résoudra le problème, mais n’ont pas le temps d’écrire le code de la meilleure façon. Dans ces situations, il est très courant de se retrouver avec beaucoup de lignes de CSS qui ne sont plus utilisées dans aucun secteur de l'application. Les développeurs n'ont pas assez de temps pour nettoyer le code et sont obligés de publier le correctif le plus rapidement possible. Une autre situation récurrente est que pour réparer rapidement les choses cassées, les développeurs utilisent beaucoup de !important, ce qui se traduit par un code très hacky qui est difficile à maintenir, cela entraîne beaucoup de comportements inattendus et doit être refactorisé plus tard. Comme mentionné précédemment, à mesure que le code se développe, la situation ne fait qu'empirer.

L'idée de cet article est de partager des règles, des astuces et des bonnes pratiques pour rédiger un meilleur Sass. Le regroupement de ces conseils et bonnes pratiques Sass peut être utilisé comme guide de style Sass. Ce guide de style devrait aider les développeurs à éviter les situations mentionnées ci-dessus. Les règles sont regroupées en segments logiques pour faciliter le référencement, mais à la fin, vous devez les adopter et les suivre toutes. Ou du moins, la plupart d'entre eux.

Guide de style

L'ensemble des règles et des meilleures pratiques de ce guide de style est adopté en fonction de l'expérience de travail avec de nombreuses équipes. Certains d'entre eux proviennent d'essais par erreur, et d'autres sont inspirés de certaines approches populaires comme BEM. Pour certaines règles, il n'y a pas de raison spécifique pour laquelle et comment elles ont été définies. Parfois, avoir l'expérience passée comme seule raison suffit. Par exemple, pour s'assurer que le code est lisible, il est important que tous les développeurs écrivent le code de la même manière, il y a donc la règle de ne pas inclure d'espaces entre parenthèses. Nous pouvons discuter s'il est préférable d'inclure l'espace entre parenthèses ou non. Si vous pensez qu'il est meilleur lorsqu'il y a des espaces entre parenthèses, ajustez ce guide de style et les règles en fonction de vos préférences. En fin de compte, l'objectif principal du guide de style est de définir des règles et de rendre le processus de développement plus standard.

L'objectif principal du guide de style est de définir des règles et de rendre le processus de développement plus standard.

Règles CSS générales

Les règles générales doivent toujours être suivies. Ils se concentrent principalement sur la manière dont le code Sass doit être formaté pour apporter cohérence et lisibilité du code:

Pour l'indentation, utilisez des espaces plutôt que des tabulations. La meilleure pratique consiste à utiliser 2 espaces. Vous pouvez exécuter votre propre guerre sacrée avec cette option, et vous pouvez définir votre propre règle et utiliser soit des onglets, soit des espaces, ou ce qui vous convient le mieux. Il est seulement important de définir une règle et de la suivre tout en étant cohérente.
Incluez une ligne vide entre chaque instruction. Cela rend le code plus lisible par l'homme et le code est écrit par des humains, n'est-ce pas?
Utilisez un sélecteur par ligne, comme ceci:

selector1, selector2 { }

N'incluez pas d'espace entre les parenthèses.

selector { @include mixin1($size: 4, $color: red); }

Utilisez des guillemets simples pour entourer les chaînes et les URL:

selector { font-family: ‘Roboto’, serif; }

Terminez toutes les règles par un point-virgule sans espaces avant:

selector { margin: 10px; }

Règles pour les sélecteurs

Ensuite, nous suivons un ensemble de règles à utiliser lors du traitement des sélecteurs:

Évitez d'utiliser des sélecteurs d'identification. Les identifiants sont trop spécifiques et utilisés principalement pour les actions JavaScript.
Évitez !important. Si vous devez utiliser cette règle, cela signifie que quelque chose ne va pas avec vos règles CSS en général, et que votre CSS n'est pas bien structuré. CSS avec plusieurs !important les règles peuvent être facilement abusées et se terminent par un code CSS compliqué et difficile à maintenir.
N'utilisez pas de sélecteur enfant. Cette règle partage le même raisonnement que celui de l'ID. Les sélecteurs enfants sont trop spécifiques et sont étroitement associés à votre structure HTML.

Si vous utilisez beaucoup! Important dans votre CSS, vous le faites mal.

Gardez vos règles Sass en ordre

Il est important de garder la cohérence dans le code. L'une des règles est que vous devez conserver l'ordre des règles. De cette façon, les autres développeurs peuvent lire le code avec beaucoup plus de compréhension et passeront moins de temps à s'y retrouver. Voici la commande proposée:

Utilisez @extend premier. Cela vous permet de savoir dans un premier temps que cette classe hérite de règles d'ailleurs.
Utilisez @include Suivant. Avoir vos mixins et fonctions inclus en haut est agréable à avoir, et vous permet également de savoir ce que vous allez écraser (si nécessaire).
Vous pouvez maintenant écrire votre classe CSS habituelle ou vos règles d'élément.
Placez les pseudo classes et pseudo éléments imbriqués avant tout autre élément.
Enfin, écrivez d'autres sélecteurs imbriqués comme dans l'exemple suivant:

.homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ‘’; } a { } ul { } }

Quelques conventions de dénomination

Une partie des conventions de dénomination du livre de styles est basée sur les deux BIEN et SMACSS conventions de dénomination devenues populaires parmi les développeurs. BEM signifie Block, Element, Modifier. Il a été développé par l'équipe YANDEX, et l'idée derrière BEM était d'aider les développeurs à comprendre la relation entre HTML et CSS dans le projet. SMACSS, quant à lui, signifie Architecture évolutive et modulaire pour CSS. C'est un guide pour structurer CSS pour permettre la maintenabilité.

Inspirées par eux, nos règles de conventions de dénomination sont les suivantes:

Utilisez le préfixe pour chaque type d'élément. Préfixez vos blocs, comme: dispositions (l-), modules (m-) et états (is-).
Utilisez deux traits de soulignement pour les éléments enfants pour chaque bloc:

.m-tab__icon {}

Utilisez deux tirets pour les modificateurs pour chaque bloc:

.m-tab--borderless {}

Variables

Utilisez des variables. Commencez par les variables plus générales et globales comme les couleurs et créez un fichier séparé pour elles _colors.scss. Si vous remarquez que vous répétez plusieurs fois une valeur sur la feuille de style, créez une nouvelle variable pour cette valeur. S'il vous plaît SEC . Vous serez reconnaissant lorsque vous voudrez changer cette valeur, et lorsque vous aurez besoin de la changer à un seul endroit.

Utilisez également un trait d'union pour nommer vos variables:

$red : #f44336; $secondary-red :#ebccd1;

Requêtes médias

Avec Sass, vous pouvez écrire vos requêtes multimédias sous forme de requêtes d'élément. La plupart des développeurs écrivent des requêtes multimédias dans un fichier séparé ou en bas de nos règles, mais cela n'est pas recommandé. Avec Sass, vous pouvez écrire des choses comme l'exemple suivant en imbriquant des requêtes multimédias:

// ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Cela génère un CSS comme celui-ci:

les langages déclaratifs sont couramment utilisés pour les applications de production.

// Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Ces règles de requêtes multimédias imbriquées vous permettent de savoir très clairement quelles règles vous écrasez, comme vous pouvez le voir dans l'extrait de code Sass où les requêtes multimédias nommées sont utilisées.

Pour créer des requêtes multimédias nommées, créez votre mixin comme ceci:

@mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Vous pouvez en savoir plus sur l'attribution de noms aux requêtes multimédias dans les articles suivants: Attribution d'un nom aux requêtes multimédias et Rédigez de meilleures requêtes multimédias avec Sass .

autres considérations

En fin de compte, voici quelques autres considérations que vous devez également garder à l'esprit et suivre:

N'écrivez jamais de préfixes de fournisseur. Utilisation préfixeur automatique au lieu.
Utilisez au maximum trois niveaux de profondeur dans les règles imbriquées. Avec plus de trois niveaux imbriqués, le code sera difficile à lire, et peut-être que vous écrivez un sélecteur de merde. En fin de compte, vous écrivez du code CSS à coupler avec votre HTML.

.class1 { .class2 { li { //last rules } } }

N'écrivez pas plus de 50 lignes de code imbriqué: ou mieux, n'écrivez pas plus de X lignes de code imbriqué. Configurez votre propre X, mais 50 semble être une bonne limite. Si vous dépassez cette limite, le bloc de code ne rentrera peut-être pas dans la fenêtre de votre éditeur de texte.
Écrivez un fichier principal dans lequel vous importerez tous vos blocs, partiels et configurations.
Importez d'abord les dépendances de fournisseur et globales, puis les dépendances créées, puis les mises en page, les modèles et enfin les pièces et les blocs. Ceci est important pour éviter les importations mixtes et l'écrasement des règles, car le fournisseur et les règles globales ne peuvent pas être gérés par nous.
Ne soyez pas timide et divisez votre code en autant de fichiers que possible.

Conclusion

L'idée derrière ce guide de style est de vous donner quelques conseils sur la façon d'améliorer la façon dont vous écrivez votre code Sass. Veuillez garder à l'esprit que même si vous n'utilisez pas Sass, les conseils et règles fournis dans ce guide de style sont également applicables et qu'il est recommandé de suivre si vous utilisez Vanilla CSS ou un autre préprocesseur. Encore une fois, si vous n’acceptez aucune des règles, modifiez la règle en fonction de votre façon de penser. En fin de compte, c'est à vous et à votre équipe d'adapter ce guide de style, d'utiliser un autre guide de style ou d'en créer un complètement nouveau. Définissez simplement le guide et commencez à écrire un code génial.

En relation: * Explorer SMACSS: architecture évolutive et modulaire pour CSS *