Web Front-End

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

Escrever CSS consistente e legível com boa escalabilidade é 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 os desenvolvedores escreverem CSS melhor são os pré-processadores. Um pré-processador é um programa que pega um tipo de dados e os converte em outro tipo de dados e, em nosso caso, os pré-processadores CSS são linguagens de pré-processamento que são compiladas para CSS. Existem muitos pré-processadores CSS que desenvolvedores front-end estão recomendando e usando, mas neste artigo vamos nos concentrar no Sass. Vamos ver o que Sass tem a oferecer , por que é uma escolha preferível 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 aqueles que não sabem o que é Sass, o melhor ponto de partida é visitar o página oficial da Sass . Sass é um acrônimo para Syntactically Awesome StyleSheets, e é uma extensão do CSS que adiciona poder e elegância à linguagem básica.

Com Sass (Syntactically Awesome StyleSheets), seu código CSS também será incrível.

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

As variáveis armazenam informações que podem ser reutilizadas posteriormente, como cores ou outros valores comumente usados. Extensões ajudam a criar “classes” que permitem herança para as regras. Mixins, você pode pensar em “função”. Sass também tem 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 Compasso , e muitos mais. Esses recursos por si só podem ajudar você e sua equipe a serem mais produtivos e a escreverem 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 escalonável e legível, e precisa evitar código espaguete e linhas não utilizadas dele. Para evitar os problemas mencionados, é necessário algum tipo de padrão para sua equipe no trabalho diário. O que é código 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 utilizadas 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 mais tarde. Conforme já mencionado, conforme o código cresce, a situação só piora.

A ideia deste artigo é compartilhar regras, dicas e práticas recomendadas para escrever um Sass melhor. O agrupamento dessas dicas e práticas recomendadas do Sass pode ser usado como um guia de estilo do 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 melhores práticas neste guia de estilo é adotado com base na experiência de trabalho com várias equipes. Alguns deles vêm de tentativa por erro e outros são inspirados por algumas abordagens populares como o BEM. Para algumas regras, não há um motivo específico por que e como foram definidas. Às vezes, ter a experiência passada como a única razão é o suficiente. Por exemplo, para garantir que o código seja legível, é importante que todos os desenvolvedores escrevam o código da mesma maneira, portanto, há 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 principal objetivo do guia de estilo é definir regras e tornar o processo de desenvolvimento mais padronizado.

O principal objetivo 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 se concentram principalmente em como o código Sass deve ser formatado para trazer consistência e legibilidade ao 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 você pode definir sua própria regra e usar guias, espaços ou o que melhor lhe convier. É importante apenas definir uma regra e seguir essa regra, sendo consistente.
Inclua uma linha em branco entre cada declaraçã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; }

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

selector { margin: 10px; }

Regras para Seletores

Em seguida, estamos seguindo um conjunto de regras a serem usadas 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 esta regra, significa que algo está errado com suas regras CSS em geral e que seu CSS não está bem estruturado. CSS com muitos !important as regras podem ser facilmente abusadas e resultam em código CSS confuso e difícil de manter.
Não use o seletor filho. Esta regra compartilha o mesmo raciocínio do ID. Os seletores filhos são muito específicos e estão intimamente ligados à sua estrutura HTML.

Se você está usando muito! Important em seu CSS, está fazendo errado.

Mantenha suas regras de 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 perderão menos tempo tentando encontrar o caminho. Aqui está o pedido proposto:

Use @extend primeiro. Isso permite que você saiba a princípio que essa classe herda regras de outro lugar.
Use @include Next. Ter seus mixins e funções incluídos no topo é bom de ter, e também permite que você saiba o que será sobrescrito (se necessário).
Agora você pode escrever sua classe CSS regular ou regras de elemento.
Coloque pseudo classes e pseudo elementos aninhados antes de qualquer outro elemento.
Finalmente, 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

Parte das convenções de nomenclatura do livro de estilos é baseada nas duas BEM e SMACSS convenções de nomenclatura 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.

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

Use o 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 travessões 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ê notar que está repetindo algum valor na folha de estilo várias vezes, vá e crie uma nova variável para esse valor. Por favor SECO . Você será 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: Naming Media Queries e Escreva melhores consultas de mídia 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 fornecedor. Usar autoprefixer em vez de.
Use no máximo três níveis de profundidade em 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 de baixa qualidade. No final, você está escrevendo um 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 editor de texto.
Escreva um arquivo principal onde você importará todos os seus blocos, parciais e configurações.
Importe primeiro o fornecedor e as dependências globais, depois as dependências criadas, depois os layouts, os padrões e, por fim, as peças e blocos. Isso é importante para evitar importações mistas e substituição de regras, porque o fornecedor e as regras globais não podem ser gerenciadas por nós.
Não seja tímido e quebre seu código no máximo de arquivos possível.

Conclusão

A ideia por trás deste guia de estilo é fornecer 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 o Sass, as dicas e regras fornecidas neste guia de estilo também são aplicáveis e recomendadas para seguir se você usar o Vanilla CSS ou outro pré-processador. Novamente, se você não concorda com nenhuma das regras, mude a regra para se adequar à sua maneira de pensar. No final, cabe a você e sua equipe adaptar este guia de estilo, usar algum outro guia de estilo ou criar um completamente novo. Basta definir o guia e começar a escrever um código incrível.

Relacionado: * Explorando SMACSS: Arquitetura Escalável e Modular para CSS *