Como otimizar o CSS com guias de estilo de código

Quando os designers falam sobre guias de estilo, eles geralmente significam um manual acordado no olhar coerente e sentir de um site ou aplicativo, com um design bem esquema de cores, tipografia e interface do usuário que é usado em todo o projeto.

Há outro tipo de guia de estilo que podemos usar no desenvolvimento da web também, e é tão importante quanto muito mais raramente discutido: guias de estilo para o próprio código. Guias de estilo de código são mais para desenvolvedores do que para designers, e seu principal objetivo é otimizar o CSS ou outro código.

Colocar em uso as guias de estilo de código adequadas nos fornece um melhor base de código organizada e consistente, melhor legibilidade do código e código mais sustentável. Não é coincidência que grandes empresas de tecnologia, como Google, AirBnB ou Dropbox, façam bom uso delas.

Neste post, vamos dar uma olhada em como podemos otimizar de forma inteligente nosso CSS com a ajuda de guias de estilo de código CSS.

Guias de estilo de código vs. bibliotecas padrão

Em nossa indústria há um certo grau de incerteza sobre o que podemos chamar de guia de estilo. Uma lista separada por exemplo, usa-o como sinônimo do termo biblioteca de padrões neste artigo, mas podemos encontrar esse tipo de definição em outros posts também.

Por outro lado, há também publicações, como CSS Tricks ou o blog de Brad Frost, que distinguem os guias de estilo de código das bibliotecas de padrões. Esta última abordagem provavelmente nos aproxima de um site bem otimizado, como nos permite lidar com código e design separadamente, então vamos usar isso neste post.

Os guias de estilo de código e as bibliotecas de padrões incluem uma estratégia de estilo, mas um tipo diferente. Bibliotecas padrão, como Bootstrap, Zurb Foundation, Global Experience Language da BBC ou biblioteca de padrões do MailChimp, nos fornecem uma interface do usuário com classes CSS premade, tipografia, esquema de cores, às vezes um sistema de grade e outros padrões de projeto.

Guias de estilo de código CSS, como o Evernote ou o ThinkUp (ou os mencionados na introdução) contêm regras sobre como escrever CSS incluindo coisas como convenções de nomenclatura, estrutura de arquivos, ordem de propriedade, formatação de código, e outros.

Observe que os geradores de guia de estilo de vida, como KSS, Styledown ou Pattern Lab, gerar bibliotecas de padrões e não guias de estilo de codificação. Embora as bibliotecas de padrões também sejam altamente úteis e elevem o processo de desenvolvimento da Web, elas não nos permitem otimizar o próprio código.

Crie seu guia de estilo de código CSS

O objetivo final de um guia de estilo de código CSS é garantir que possamos trabalhar com uma base de código consistente e facilmente depurável escrita por desenvolvedores que seguem as mesmas regras de estilo de código. Criar um guia de estilo de código CSS pode levar um pouco de tempo, mas vale a pena o esforço, pois só precisamos fazer isso uma vez. Então podemos usar o mesmo guia de estilo em diferentes projetos.

É importante notar que os melhores guias de estilo não contém apenas as regras de estilo, mas também exemplos de bom e mau uso, assim os desenvolvedores podem entender mais intuitivamente as regras.

Por exemplo, o AirBnB mostra bons e maus exemplos para os desenvolvedores da seguinte maneira facilmente digerível:

Estrutura dos arquivos

Primeiro, precisamos descobrir uma lógica de acordo com a qual organizaremos nossos arquivos CSS. Para projetos menores, um arquivo CSS pode ser suficiente, mas para arquivos maiores é sempre melhor quebrar o código, e concatenar os arquivos separados posteriormente em produção.

Alguns guias de estilo, como o do ThinkUp, também nos alertam sobre não usando estilos embutidos ou incorporados a menos que seja inevitável; também é uma regra útil que vale a pena aplicar.

Aninhamento

O aninhamento é um ótimo recurso no CSS, mas às vezes pode sair do controle. Ninguém se sente particularmente feliz, especialmente no meio de um frustrante processo de depuração, esbarrando em seletores extra longos como este:

 .class_1 .class_2 # id_1 # id_2 li um período color: #bad; 

Então é sempre bom configurar um limite de aninhamento razoável, por exemplo, o GitHub escolheu três níveis em seu guia de estilo. Ao limitar o aninhamento, podemos também nos forçar a escrever um código melhor estruturado.

Regras de Nomenclatura

Usar regras de nomenclatura coerentes para seletores de CSS é crucial se quisermos entender nosso código meses ou mesmo anos depois. Existem muitas soluções por aí e há apenas uma regra estrita que precisamos seguir ou seja, um nome de seletor não pode começar com um número.

Os quatro estilos comuns usados ​​na nomenclatura do seletor são .minúsculas, .under_scores, .traço-es, e .lowerCamelCase. Não há problema em escolher qualquer um deles, mas precisamos seguir a mesma lógica em todo o projeto.

Usando somente nomes de seletores semânticos também é essencial se quisermos ter um código significativo. Por exemplo, em vez de .botão vermelho (o que não mostra o que o botão faz) é melhor usar o .botão de alerta name (que diz o que faz), desta forma, nós permitimos que os desenvolvedores (e nossos futuros eus) entendam o que o botão faz.

Além disso se quisermos mudar sua cor de vermelho para outra coisa no futuro, podemos facilmente fazê-lo sem problemas. Existem também convenções de nomenclatura CSS premade, como a convenção BEM (Block, Element, Modifier), que resultar em uma estrutura de nomenclatura consistente com nomes únicos e significativos.

Regras de formatação

A formatação de código inclui coisas como o uso de espaço em branco, guias, recuo, espaçamento, quebras de linha, etc. Não existe realmente um método universalmente bom ou ruim na formatação, a única regra é escolha regras coerentes que resultem em um código legível, e segui-los.

O Dropbox, por exemplo, exige que os desenvolvedores coloquem espaços após os dois-pontos nas declarações de propriedade, enquanto o Evernote usa dois espaços para recuo. Podemos configurar tantas regras de formatação quanto nos sentimos confortáveis, mas nunca mais do que é possível entender.

Ordem de declaração

Coisas ordenadas são sempre mais fáceis de ver e pedidos de declarações CSS (propriedades com seus valores) de acordo com uma regra que faz sentido resulta em um código melhor organizado.

Dê uma olhada, por exemplo, nas regras de ordenação de propriedade do WordPress, ele define a seguinte linha de base simples, mas lógica, para ordenação em que as propriedades são agrupadas por seus significados:

1. Exibição
2. Posicionamento
3. Modelo de caixa
4. Cores e Tipografia
5. De outros

Unidades e Valores

Decidir como queremos usar unidades e valores não é importante apenas para obter uma aparência de código consistente, mas também, se não o fizermos, podemos acabar com algo estranho.

Imagine um site que use alternadamente px, em, e rem medições de comprimento. Não vai parecer ruim apenas no editor de código, mas provavelmente alguns elementos serão surpreendentemente pequenos ou grandes nesse site..

Também precisamos tomar decisões sobre valores de cores (hexadecimal, rgb ou hsl) e se queremos usar propriedades abreviadas e de acordo com quais regras. Há uma instrução incluída em todos os guias de estilo de código CSS que eu encontrei, por exemplo. não especifica unidades para valores 0 (na verdade, apenas não).

.class // boa margem: 0; // margem ruim: 0px; // margem ruim: 0em; // margem ruim: 0rem; 

Comentando

Comentar código é essencial em todos os idiomas, mas em CSS ele não apenas facilita a depuração e a criação de documentação, mas também as seções de regras CSS em grupos lógicos. Podemos usar o / *… * / ou o //… notação estilo para comentários em CSS, o importante é fique consistente com comentários em todo o nosso projeto.

O CSS idiomático, por exemplo, estabelece um sistema de comentários significativo que usa até mesmo alguma arte ASCII básica e resulta em um código bem organizado: