Um problema muito comum quando trabalhamos em equipe é a inconsistência no estilo de codificação. Uns preferem colocar as propriedades do CSS em uma única linha, outros não. Uns gostam de colocar espaço depois dos dois-pontos, outros não. No fim, acaba tudo uma zona. São muitos desenvolvedores, escrevendo de formas totalmente distintas, o que prejudica qualquer tipo de manutenção ou evolução do código.
Por isso, tenho notado um movimento cada vez maior de empresas buscando padronizar seu estilo de código. Google, Github e muitas outras já disponibilizaram publicamente seus guias de estilo:
Pensando nisso, Nicolas Gallagher (@necolas), funcionário do Twitter, criador do Normalize.css e um dos líderes do HTML5 Boilerplate, resolveu criar um guia chamado Idiomatic CSS – Princípios para escrever CSS de forma consistente e idiomática. Baseado em um projeto semelhante, porém com foco em JavaScript, o idiomatic.js.
O que eu irei apresentar hoje é uma pequena adaptação da tradução oficial, feita por mim, desse documento vivo e aberto para contribuições através do Github photoalbum download for free.
O guia a seguir não pretende ser prescritivo e também não busca impor as preferências do autor no código de outras pessoas. Entretanto, estas orientações incentivam fortemente o uso de padrões já existentes, comuns e sensatos.
Todo código em qualquer aplicação deve parecer como se tivesse sido escrito por uma única pessoa, independentemente de quantas pessoas tenham contribuído. Faça cumprir rigorosamente o estilo acordado.
Novamente, apenas um estilo deve existir em todo o projeto. Seja sempre consistente na utilização de espaços em branco. Use espaços em branco para melhorar a legibilidade.
Dica: configure seu editor para “mostrar invisíveis”. Isso irá permitir que você elimine espaços em branco da quebra de linha, elimine espaços em branco de linhas vazias sem indentação e evite commits poluídos.
Código bem comentado é extremamente importante. Tire tempo para descrever componentes, como eles funcionam, suas limitações e o modo como são construídos. Não deixe outros no time adivinharem o propósito de códigos incomuns ou não óbvios.
Estilo de comentário deve ser simples e consistente dentro de uma única base de código windows 7 ultimate 64 bit downloaden.
Dica: configure seu editor para lhe prover com atalhos a geração do padrão de comentários acordado.
/* ==========================================================================
Bloco de comentário de seção ========================================================================== */ /* Bloco de comentário de sub-seção /* /* Comentário básico */ |
// ==========================================================================
// Bloco de comentário de seção // ========================================================================== // Bloco de comentário de sub-seção // // Comentário básico |
O formato de código escolhido deve garantir que o código seja: fácil de ler; fácil de comentar claramente; minimize a chance de introduzir erros acidentalmente; e resulte em úteis visualizações de diferença.
.seletor-1,
.seletor-2, .seletor-3 { -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; display: block; color: #333; background: #fff; } |
Declarações devem ser ordenadas segundo um único princípio. Minha preferência é por propriedades relacionadas para serem agrupadas e por propriedades estruturalmente importantes (por exemplo, posicionamento e box-model) para serem declaradas antes de propriedades tipográficas, fundo ou cor.
.seletor {
position: relative; display: block; width: 50%; height: 100px; padding: 10px; border: 0; margin: 10px; color: #fff background: #000; } |
Ordenação alfabética também é popular, mas a desvantagem é que ela separa as propriedades relacionadas. Por exemplo, deslocamentos de posição não são mais agrupados e propriedades do box-model podem acabar propagando ao longo de um bloco de declaração bluemail for android.
Grandes blocos de declarações individuais podem atuar de forma diferente, através da formatação de linha única. Nesse caso, um espaço deve ser considerado depois da abertura das chaves e antes do fechamento das chaves.
1
2 3 |
.seletor-1 { width: 10%; }
.seletor-2 { width: 20%; } .seletor-3 { width: 30%; } |
Longos valores de propriedades separados por vírgula – como coleções de degradês ou sombras – podem ser organizados em várias linhas em um esforço para melhorar a legibilidade e produz visualizações de diferença mais úteis. Existem vários formatos que poderiam ser usados; um exemplo é mostrado abaixo.
.seletor {
box-shadow: 1px 1px 1px #000, 2px 2px 1px 1px #ccc inset; background-image: linear-gradient(#fff, #ccc), linear-gradient(#f3c, #4ec); } |
Use valores hexadecimais em letras minúsculas, por exemplo:
1
|
#aaa
|
Use aspas simples ou duplas de forma consistente. Preferência por aspas duplas, por exemplo:
1
|
content: ""
|
Sempre coloque aspas em valores de atributos nos seletores, por exemplo:
1
|
input[type="checkout"]
|
Onde permitido, evite especificar unidades para valores-zero, por exemplo:
1
|
margin: 0
|
Diferentes pré-processadores de CSS possuem diferentes características, funcionalidades e sintaxe Download story sticker. Suas convenções devem ser extendidas para acomodar as particularidades de qualquer pré-processador em uso. As seguintes diretrizes são em referência ao Sass.
.seletor-1 {
@extend .other-rule; @include clearfix(); @include box-sizing(border-box); width: x-grid-unit(1); // outras declarações } |
Você não é um compilador/compressor de código humano, então não tente ser.
Use nomes claros e previdentes para classes HTML. Escolha um padrão de nomes compreensível e consistente que faça sentido para arquivos HTML e arquivos CSS.
/* Exemplo de código com nomes ruins */
.s-scr { .cb { /* Exemplo de código com bons nomes */ .is-scrollable { .column-body { |
Um exemplo de várias convenções.
/* ==========================================================================
Grid layout ========================================================================== */ /* .grid { .cell { /* Células – Estados */ .cell.is-animating { /* Células – Dimensões .cell-1 { width: 10%; } /* Células – Modificadores .cell–detail, |
Organização de código é uma importante parte de qualquer base de código CSS, e crucial para grandes bases de código.
Os projetos devem sempre tentar incluir alguns meios genéricos pelos quais sua fonte possa ser avaliada, testada, comprimida e versionada em preparação para uso em produção Minecraft full version german for free. Para essa tarefa, o grunt por Ben Alman é uma excelente ferramenta.
Independemente de você ter concordado ou não com o guia de estilo proposto, o importante é entender como uma padronização no estilo do código pode ajudar você e sua equipe. Pense nisso.
Fonte: Tableless