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

Rédiger un CSS cohérent et lisible qui évoluera bien est un processus difficile. Surtout lorsque les feuilles de style deviennent plus grandes, plus complexes et plus difficiles à maintenir. L'un des outils disponibles pour les développeurs pour écrire de meilleurs CSS sont les préprocesseurs. 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 que les développeurs frontaux recommandent et utilisent, mais dans cet article, nous nous concentrerons sur Sass. Voyons ce que 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 la page Web officielle de Sass. Sass est un acronyme pour Syntactically Awesome StyleSheets, et est une extension de CSS qui ajoute de la puissance et de l'élégance au langage de base.

Sass est un préprocesseur CSS doté de nombreuses fonctionnalités puissantes. Les fonctionnalités les plus notables sont les variables, les extensions et les mixins.

Les variables stockent des informations qui peuvent être réutilisées ultérieurement, comme les couleurs ou d'autres valeurs couramment utilisées. Les extensions vous aident à créer des "classes" qui permettent l'héritage des règles. Mixins, vous pouvez penser à "fonction". Sass possède également d'autres fonctionnalités étonnantes par rapport à d'autres préprocesseurs, comme l'utilisation d'instructions logiques (conditions et boucles), des fonctions personnalisées, l'intégration avec d'autres bibliothèques comme Compas, et bien d'autres. Ces fonctionnalités à elles seules peuvent vous aider, vous et votre équipe, à être plus productifs et à écrire de meilleurs CSS au final.

Pourquoi avez-vous 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 chaque développeur est confronté 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 le code spaghetti et les 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 produit-il ? Le code spaghetti est un nom pour un code mauvais, lent, répétitif et illisible. Lorsqu'une équipe écrit de grandes 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 de nombreuses 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 ils sont obligés de publier le correctif le plus rapidement possible. Une autre situation récurrente est que pour réparer rapidement les problèmes, les développeurs utilisent beaucoup de !important , ce qui se traduit par un code très piraté difficile à maintenir, il en résulte de nombreux comportements inattendus et doit être refactorisé ultérieurement. Comme déjà mentionné, à mesure que le code grandit, 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 écrire 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 en fin de compte, vous devez toutes les adopter et les suivre. 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é sur la base d'une expérience de travail avec de nombreuses équipes. Certains d'entre eux proviennent d'essais par erreurs, 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 existe 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 que c'est mieux quand il y a des espaces entre parenthèses, ajustez ce guide de style et ces règles selon vos préférences. En fin de compte, l'objectif principal du guide de style est de définir des règles et de standardiser le processus de développement.

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é au code :

• Pour l'indentation, utilisez des espaces au lieu de tabulations. La meilleure pratique consiste à utiliser 2 espaces. Vous pouvez mener 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 suivre cette règle tout en étant cohérent.
• Insérez 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 espace avant :

 selector { margin: 10px; }

Règles pour les sélecteurs

Ensuite, nous suivons un ensemble de règles à utiliser lorsqu'il s'agit de sélecteurs :

• Évitez l'utilisation de sélecteurs d'ID. Les identifiants sont trop spécifiques et utilisés principalement pour les actions JavaScript.
• Evitez !important . Si vous avez besoin d'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 de nombreuses règles !important peut être facilement abusé et se retrouver avec un code CSS désordonné et difficile à maintenir.
• N'utilisez pas de sélecteur enfant. Cette règle partage le même raisonnement que celle de l'ID. Les sélecteurs enfants sont trop spécifiques et étroitement liés à votre structure HTML.

Gardez vos règles Sass en ordre

Il est important de garder une cohérence dans le code. L'une des règles est que vous devez garder 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 :

1. Utilisez d'abord @extend . Cela vous a fait savoir dans un premier temps que cette classe hérite des règles d'ailleurs.
2. Utilisez @include ensuite. 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).
3. Vous pouvez maintenant écrire vos règles de classe ou d'élément CSS habituelles.
4. Placez les pseudo-classes et les pseudo-éléments imbriqués avant tout autre élément.
5. 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 nommage

Une partie des conventions de nommage du livre de style est basée sur les deux conventions de nommage BEM et SMACSS existantes qui sont devenues populaires parmi les développeurs. BEM signifie bloc, élément, modificateur. 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 Scalable and Modular Architecture for CSS. C'est un guide pour structurer le CSS afin de permettre la maintenabilité.

Inspirées par elles, nos règles de conventions de nommage sont les suivantes :

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

 .m-tab__icon {}

• Utilisez deux tirets pour les modificateurs de 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. Veuillez SÉCHER. Vous serez reconnaissant lorsque vous voudrez modifier cette valeur et lorsque vous aurez besoin de la modifier à un seul endroit.

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

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

Requêtes multimédias

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

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

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

 // 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 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 la dénomination des requêtes multimédias dans les articles suivants : Naming Media Queries et Write Better Media Queries with Sass.

autres considérations

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

• N'écrivez jamais de préfixes de fournisseur. Utilisez plutôt le préfixe automatique.
• 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 vous écrivez peut-être 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 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 nous ne pouvons pas gérer les règles du fournisseur et les règles globales.
• 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. N'oubliez pas que même si vous n'utilisez pas Sass, les conseils et règles fournis dans ce guide de style sont également applicables et recommandés si vous utilisez Vanilla CSS ou un autre préprocesseur. Encore une fois, si vous n'êtes pas d'accord avec l'une des règles, modifiez la règle pour l'adapter à 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.