Como organizar os códigos-fonte

TL;DR

Organizar o código-fonte com OOCSS, BEM e SMACSS reduz atrito de manutenção quando o projeto e o time crescem. BEM padroniza Bloco, Elemento e Modificador; OOCSS e SMACSS oferecem outras lentes de arquitetura CSS modular.

  • Por que importa: estrutura confusa atrasa manutenção e escala mal mesmo com Git no fluxo.
  • Como funciona: OOCSS separa preocupações em objetos; BEM nomeia bloco, elemento e modificador.
  • Em detalhe: no BEM, bloco tem sentido sozinho; elemento depende do bloco; modificador altera aparência ou comportamento.
  • Na prática: SMACSS entra como outra metodologia popular de arquitetura CSS escalável.
  • Conclusão: escolha uma convenção e documente-a para o time antes do próximo epic.

Desenvolvedores web experientes podem se deparar constantemente com o problema da falta de organização e clareza do seu código-fonte. No início isso não era problema, principalmente em virtude do tamanho e da complexidade dos projetos, que eram reduzidos. Hoje, no entanto, uma estrutura incorreta pode causar vários problemas, como a dificuldade de realizar manutenções no código da aplicação.

Outro ponto que justifica a necessidade de organizar o código-fonte é quando uma equipe atua em um projeto. Mesmo usando o GitHub para gerenciar as alterações, muitas pessoas codificando tendem a aumentar o risco de desorganização, prejudicando, além da manutenção, a escalabilidade da aplicação.

Neste texto, vamos falar sobre algumas metodologias usadas no CSS, de modo a promover a melhor organização do seu código-fonte. Continue lendo!

Neste post 4

OOCSS

O OOCSS é uma metodologia focada em uma abordagem de orientação a objetos. Portanto, a ideia é fazer a separação entre contêiner, conteúdo, visual e estrutura. Quando o desenvolvedor se depara com um grande projeto, é quase inevitável ter que repetir estruturas em CSS na hora de descrever a posição e a largura dos componentes, por exemplo.

BEM

O método BEM (Block, Element and Modifier) é bastante útil na hora de reutilizar código CSS. O objetivo é criar componentes e padronizar a nomeação das classes, de modo a agilizar o desenvolvimento, promovendo escalabilidade e facilidade de manutenção no futuro.

Bloco

Um bloco deve ser independente e único no código. Além disso, precisa ser construído antes dos demais elementos, sendo que dentro dele é possível inserir outros blocos, por exemplo. Imagine uma parte do layout de uma página web composta pela área de login, pesquisa, menu e logo. Cada um desses que foram citados podem ser blocos independentes inseridos em um bloco maior, que podemos chamar de head.

Admito que, na pressa ou pelo costume, já me vi nomeando classes no puro improviso—um “.box1” aqui, um “.caixa-vermelha” ali, daquele jeito que funciona só até alguém precisa mexer. A real é que a metodologia BEM não resolve tudo de forma mágica, mas ela te força a um pensamento mais ordenado do que aquela gambiarra rápida de sexta-feira à tarde. Isso já evita um bom bocado de dor de cabeça no futuro. E claro, nenhum desenvolvedor é 100% disciplinado o tempo inteiro, mas criar uma base minimamente lógica é um favor que você faz pra você mesmo e pra quem mexer no seu código depois.

No começo, esse processo pode parecer excessivo, talvez até burocrático demais. Tipo, por que complicar com nomes longos quando só tem você na equipe, certo? Mas, sinceramente, quando o projeto cresce e mais gente começa a colocar a mão na massa, o negócio muda. A clareza que o BEM oferece na nomenclatura começa a fazer diferença de verdade. É meio invisível até você esbarrar em um CSS perdido, daqueles que ninguém tem coragem de alterar. Aí sim percebe o valor disso.

Considere, neste exemplo, um bloco desse head chamado logo. Com a utilização do método BEM, “logo” pode ser inserido em outras áreas de “head”, sem interferir nas demais funcionalidades. Portanto, a ideia é atribuir não uma característica de estilo ao bloco, mas sim a sua semântica.

Em outras palavras, na hora de dar nome à classe, deve-se dizer se é um Form, Navbar ou Menu, por exemplo, em vez de dizer a cor do texto. Essa mudança traz muito mais clareza não só ao desenvolvedor, mas também às pessoas que terão contato com esse código no futuro, fazendo atualizações ou manutenções.

Elemento

O elemento não só depende de um bloco, como de outros componentes para fazer sentido. Em relação à nomenclatura de classes o seu funcionamento é semelhante ao bloco, prezando mais pela sua semântica do que pelo estilo ou estado. Em uma barra de pesquisa, por exemplo, é possível ter dois elementos, que podem ser chamados input e button, que existem dentro de um bloco que podemos nomear de Form.

Modificador

O modificador tem uma característica menos semântica e mais voltada para o que o bloco ou o elemento fazem. Costuma ser adotado quando elementos e blocos diferem justamente nas suas definições de estilo e estado. Imagine um menu que aparece tanto no cabeçalho como no rodapé de uma página. Nesse caso, será criado um modificador para realizar mudanças no cabeçalho e no rodapé, usando descrições como:

  • focused ou disable, apontando característica de estado;
  • color-red, descrevendo a aparência do bloco ou elemento;
  • directions_left-top e change-to-right, apontando um comportamento.

SMACSS

O SMACSS (Scalable and Modular Architecture for CSS) é uma das metodologias mais populares em organização de código. Desenvolvido pela Yahoo!, é composto pelas categorias Base, Layout, Module, State e Theme. Acompanhe cada um deles nas subseções a seguir.

Base

Imagine uma tag de parágrafo no HTML configurada no CSS para apresentar a cor azul. Quando isso ocorre, temos a seleção por elemento, que é justamente o foco da categoria Base no SMACSS, dispensando, portanto, o uso de classes e IDs. A proposta é criar uma página web padronizada, sendo que, ao invés de usar somente a tag de parágrafo, por exemplo, podem ser incluídas na sintaxe:

  • hierarquias de títulos (h1, h2, h3 e assim por diante);
  • formulários;
  • tabelas;
  • legendas;
  • artigos;
  • rodapés;
  • imagens, entre outros.

Layout

Os cabeçalhos e rodapés de uma página, por serem estruturas fixas, podem ser organizados pela categoria de Layout do SMACSS. Frameworks CSS como o Bootstrap e o Pure utilizam o layout para poupar tempo dos desenvolvedores web, visto que eles entregam estruturas prontas de uma página web.

Module e State

Ao contrário do layout que lida com as estruturas fixas de um website, o Module do SMACSS é responsável pela parte reutilizável do código, ou os componentes. Os botões, menus de navegação e alertas são os melhores exemplos disso, sendo algo crucial para assegurar a escalabilidade e a facilidade de realizar manutenções no código.

Sobre o State (estado), algumas opções são .is-active, .is-selected e .is-visible. Percebe-se o uso do prefixo .is-, necessário para distinguir um estado específico em relação às outras classes.

Theme

A categoria Theme, por sua vez, tem bastante relevância na hora de personalizar a experiência dos usuários em um website. O código-fonte de uma loja virtual, por exemplo, pode precisar do Theme para ficar mais organizado, dado que se trata de uma aplicação de maior porte.

ITCSS

O ITCSS (Inverted Triangle CSS) tem a proposta de organizar o código-fonte por meio de camadas. Para simbolizar um triângulo invertido, essa segmentação é feita na seguinte ordem, considerando sete seletores:

  1. Settings: corresponde às configurações básicas, como cores, fontes e variáveis globais do CSS;
  2. Tools: representam os estilos e o layout do website;
  3. Generic: aqui são usadas as propriedades mais genéricas do CSS;
  4. Elements: aqui não se usa classe ou id, somente a seleção por elemento, de forma semelhante à categoria Base do SMACSS;
  5. Objects: diferente da camada anterior, aqui é permitida a seleção por classe;
  6. Components: aqui já é possível trabalhar com uma grande gama de elementos de interface;
  7. Trumps: a camada mais específica de todas, sendo que um exemplo bastante conhecido é a classe .hidden em conjunto com a instrução !important.

Organizar o código-fonte, como vimos ao longo do texto, é crucial em projetos web de grande porte. Dessa forma, o desenvolvedor não se perde na hora de codificar, tendo clareza de todas as partes, de modo a facilitar a manutenção por terceiros e permitir a sua escalabilidade.

Perguntas frequentes

Quando o artigo recomenda cuidar da organização do código-fonte?

Quando o projeto deixa de ser pequeno e a falta de clareza começa a dificultar manutenção, ou quando várias pessoas codificam no mesmo repositório. Git ajuda no histórico, mas não substitui convenção de estrutura. Defina a metodologia antes do código espalhar classes soltas. Revise PRs contra essa regra.

O que muda na prática ao adotar BEM?

Você padroniza nomes em Bloco, Elemento e Modificador para reutilizar CSS com menos colisão. Bloco é entidade autônoma; elemento só faz sentido no bloco; modificador altera aparência ou comportamento. Isso espelha a definição canônica do getbem e o uso descrito no guia. Comece por um componente isolado antes de renomear o legado inteiro.

OOCSS e SMACSS resolvem o mesmo problema que BEM?

Os três miram organização e escala do CSS, com ênfases diferentes. OOCSS traz lente de orientação a objetos; SMACSS aparece como arquitetura modular popular; BEM detalha a gramática de classes. Não misture as três sem um guia interno. Escolha a que o time consegue aplicar em code review.

Organizar CSS basta para times grandes?

Ajuda manutenção e escalabilidade, mas o artigo lembra que muita gente codificando aumenta risco de desorganização mesmo com GitHub. Combine metodologia com revisão e ownership de pastas. Sem acordo explícito, cada dev reinventa nomes. Trate a convenção como parte do onboarding.

MM Matt Montenegro