Guia de estilo Sass: um tutorial Sass sobre como escrever um código CSS melhor

Escrever um CSS consistente e legível que será bem dimensionado é um processo desafiador. Especialmente quando as folhas de estilo estão ficando maiores, mais complexas e mais difíceis de manter. Uma das ferramentas disponíveis para desenvolvedores escreverem CSS melhores são os pré-processadores. Um pré-processador é um programa que pega um tipo de dado e o converte em outro tipo de dado, e no nosso caso os pré-processadores CSS são linguagens de pré-processamento que são compiladas para CSS. Existem muitos pré-processadores CSS que os desenvolvedores front-end estão recomendando e usando, mas neste artigo vamos nos concentrar no Sass. Vamos ver o que o Sass tem a oferecer, por que é uma escolha preferível em relação a outros pré-processadores CSS e como começar a usá-lo da melhor maneira.

O que é Sass e por que você deve usá-lo?

Para quem não sabe o que é Sass, o melhor ponto de partida é visitar a página oficial do Sass. Sass é um acrônimo para Syntactically Awesome StyleSheets e é uma extensão do CSS que adiciona poder e elegância à linguagem básica.

Sass é um pré-processador CSS com muitos recursos poderosos. Os recursos mais notáveis ​​são variáveis, extensões e mixins.

As variáveis ​​armazenam informações que podem ser reutilizadas posteriormente, como cores ou outros valores comumente usados. As extensões ajudam você a criar “classes” que permitem herança para as regras. Mixins, você pode pensar como “função”. O Sass também possui alguns outros recursos incríveis em comparação com outros pré-processadores, como o uso de instruções lógicas (condicionais e loops), funções personalizadas, integração com outras bibliotecas como Compas e muito mais. Esses recursos por si só podem ajudar você e sua equipe a serem mais produtivos e a escrever CSS melhor no final.

Por que você precisa de um guia de estilo CSS

Infelizmente, mesmo os pré-processadores não podem consertar tudo e ajudá-lo a escrever um bom código CSS. O problema que todo desenvolvedor está enfrentando é que os aplicativos da Web atuais estão se tornando cada vez maiores. É por isso que o código precisa ser escalável e legível, e precisa evitar código espaguete e linhas não utilizadas. Para evitar problemas mencionados, é necessário algum tipo de padrão para sua equipe no trabalho diário. O que é código de espaguete e como isso acontece? Código espaguete é um nome para código ruim, lento, repetitivo e ilegível. Quando uma equipe escreve grandes aplicativos sem diretrizes ou padrões definidos, cada desenvolvedor escreve o que precisa e como deseja. Além disso, quando os desenvolvedores estão escrevendo muitas correções de bugs, hotfixes e patches, eles tendem a escrever código que resolverá o problema, mas não têm tempo para escrever o código da melhor maneira. Nessas situações, é muito comum acabar com muitas linhas de CSS que não são mais usadas em nenhum setor da aplicação. Os desenvolvedores não têm tempo suficiente para limpar o código e são forçados a publicar a correção o mais rápido possível. Outra situação recorrente é que para consertar coisas quebradas rapidamente, os desenvolvedores usam muito !important , o que resulta em um código muito hacky que é difícil de manter, resulta em muitos comportamentos inesperados e precisa ser refatorado posteriormente. Como já foi mencionado, à medida que o código cresce, a situação só piora.

A ideia deste artigo é compartilhar regras, dicas e melhores práticas para escrever um Sass melhor. Agrupar essas dicas e melhores práticas Sass pode ser usado como um guia de estilo Sass. Este guia de estilo deve ajudar os desenvolvedores a evitar as situações mencionadas acima. As regras são agrupadas em segmentos lógicos para facilitar a referência, mas no final você deve adotar e seguir todas elas. Ou pelo menos, a maioria deles.

Guia de estilo

O conjunto de regras e práticas recomendadas neste guia de estilo são adotados com base na experiência de trabalho com muitas equipes. Alguns deles vêm de tentativa por erro, e outros são inspirados por algumas abordagens populares como BEM. Para algumas regras não há uma razão específica por que e como elas foram definidas. Às vezes, ter a experiência passada como a única razão é suficiente. Por exemplo, para garantir que o código esteja legível é importante que todos os desenvolvedores estejam escrevendo o código da mesma forma, portanto existe a regra de não incluir espaços entre parênteses. Podemos discutir se é melhor incluir o espaço entre parênteses ou não. Se você acha que fica melhor quando há espaços entre parênteses, ajuste este guia de estilo e as regras de acordo com suas preferências. No final, o objetivo principal do guia de estilo é definir regras e tornar o processo de desenvolvimento mais padronizado.

Regras gerais de CSS

As regras gerais devem ser sempre seguidas. Eles são principalmente focados em como o código Sass deve ser formatado para trazer consistência e legibilidade do código:

• Para recuo, use espaços em vez de tabulações. A melhor prática é usar 2 espaços. Você pode executar sua própria guerra sagrada com esta opção e pode definir sua própria regra e usar guias, espaços ou o que melhor lhe convier. Só é importante definir uma regra e seguir essa regra sendo consistente.
• Inclua uma linha vazia entre cada instrução. Isso torna o código mais legível por humanos, e o código é escrito por humanos, certo?
• Use um seletor por linha, assim:

 selector1, selector2 { }

• Não inclua um espaço entre parênteses.

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

• Use aspas simples para incluir strings e URLs:

 selector { font-family: 'Roboto', serif; }

• Termine todas as regras com um ponto e vírgula sem espaços antes:

 selector { margin: 10px; }

Regras para seletores

Em seguida, estamos seguindo com um conjunto de regras para usar ao lidar com seletores:

• Evite o uso de seletores de ID. Os IDs são muito específicos e usados ​​principalmente para ações JavaScript.
• Evite !important . Se você precisar usar essa regra, significa que algo está errado com suas regras de CSS em geral e que seu CSS não está bem estruturado. CSS com muitas regras !important pode ser facilmente abusado e acaba com um código CSS confuso e difícil de manter.
• Não use o seletor filho. Esta regra compartilha o mesmo raciocínio que o ID. Os seletores filho são muito específicos e estão fortemente acoplados à sua estrutura HTML.

Mantenha suas regras Sass em ordem

É importante manter a consistência no código. Uma das regras é que você precisa manter a ordem das regras. Dessa forma, outros desenvolvedores podem ler o código com muito mais compreensão e gastar menos tempo procurando o caminho. Segue a ordem proposta:

1. Use @extend primeiro. Isso permite que você saiba primeiro que essa classe herda regras de outros lugares.
2. Use @include seguida. É bom ter seus mixins e funções incluídos no topo e também permite que você saiba o que será substituído (se necessário).
3. Agora você pode escrever sua classe CSS regular ou regras de elemento.
4. Coloque pseudo classes e pseudo elementos aninhados antes de qualquer outro elemento.
5. Por fim, escreva outros seletores aninhados como no exemplo a seguir:

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

Algumas convenções de nomenclatura

Convenções de nomenclatura parte do livro de estilos é baseada nas duas convenções de nomenclatura BEM e SMACSS existentes que se tornaram populares entre os desenvolvedores. BEM significa Bloco, Elemento, Modificador. Ele foi desenvolvido pela equipe YANDEX, e a ideia por trás do BEM era ajudar os desenvolvedores a entender a relação entre HTML e CSS no projeto. SMACSS, por outro lado, significa Scalable and Modular Architecture for CSS. É um guia para estruturar CSS para permitir a manutenção.

Inspirados por eles, nossas regras de convenções de nomenclatura são as seguintes:

• Use prefixo para cada tipo de elemento. Prefixe seus blocos, como: layouts ( l- ), módulos ( m- ) e estados ( is- ).
• Use dois sublinhados para elementos filho para cada bloco:

 .m-tab__icon {}

• Use dois traços para modificadores para cada bloco:

 .m-tab--borderless {}

Variáveis

Use variáveis. Comece com as variáveis ​​mais gerais e globais, como cores, e crie um arquivo separado para elas _colors.scss . Se você perceber que está repetindo algum valor na folha de estilo várias vezes, vá e crie uma nova variável para esse valor. Por favor, SEQUE. Você ficará grato quando quiser alterar esse valor e quando precisar alterá-lo em apenas um lugar.

Além disso, use um hífen para nomear suas variáveis:

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

Consultas de mídia

Com Sass você pode escrever suas consultas de mídia como consultas de elemento. A maioria dos desenvolvedores escreve consultas de mídia em um arquivo separado ou na parte inferior de nossas regras, mas isso não é recomendado. Com Sass, você pode escrever coisas como o exemplo a seguir, aninhando consultas de mídia:

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

Isso gera um CSS como este:

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

Essas regras de consultas de mídia aninhadas permitem que você saiba muito claramente quais regras você está substituindo, como você pode ver no snippet Sass onde as consultas de mídia nomeadas são usadas.

Para criar consultas de mídia nomeadas, crie seu mixin assim:

 @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; } } }

Você pode ler mais sobre como nomear consultas de mídia nos seguintes artigos: Como nomear consultas de mídia e escrever consultas de mídia melhores com Sass.

outras considerações

No final, aqui estão algumas outras considerações que você também deve ter em mente e seguir:

• Nunca escreva prefixos de fornecedores. Use prefixo automático em vez disso.
• Use no máximo três níveis de profundidade nas regras aninhadas. Com mais de três níveis aninhados, o código será difícil de ler e talvez você esteja escrevendo um seletor ruim. No final, você está escrevendo código CSS para combinar com seu HTML.

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

• Não escreva mais de 50 linhas de código aninhado: Ou melhor, não escreva mais de X linhas de código aninhado. Configure seu próprio X, mas 50 parece um bom limite. Se você ultrapassar esse limite, talvez o bloco de código não caiba na janela do seu editor de texto.
• Escreva um arquivo principal onde você irá importar todos os seus blocos, parciais e configurações.
• Importe primeiro as dependências globais e de fornecedor, depois as dependências de autoria, depois os layouts, os padrões e, finalmente, as partes e os blocos. Isso é importante para evitar importações mistas e substituição de regras, pois as regras globais e de fornecedor não podem ser gerenciadas por nós.
• Não seja tímido e divida seu código em tantos arquivos quanto possível.

Conclusão

A ideia por trás deste guia de estilo é dar alguns conselhos sobre como melhorar a maneira como você está escrevendo seu código Sass. Por favor, tenha em mente que mesmo se você não estiver usando Sass, as dicas e regras fornecidas neste guia de estilo também são aplicáveis ​​e recomendadas se você usar Vanilla CSS ou outro pré-processador. Novamente, se você não concordar com alguma das regras, mude a regra para se adequar ao seu modo de pensar. No final, cabe a você e sua equipe adaptar este guia de estilo, usar outro guia de estilo ou criar um completamente novo. Basta definir o guia e começar a escrever um código incrível.