Diretrizes de revisão de código para CSS, JS e HTML

Me pediram para criar diretrizes para revisão de CSS, JS e HTML. Eu sei que existem diretrizes de codificação para JS, mas não sei nada sobre HTML e CSS. Para revisar o JS, certamente seguirei essas diretrizes e as mencionarei. Mas e CSS e HTML? Além de erros lógicos e problemas de indentação, há alguma coisa específica que preciso verificar ao revisar a marcação e / ou CSS?

Algumas coisas a procurar:

• As informações estruturadas são identificadas usando as tags HTML apropriadas? H1- H6para títulos, UL/ OLe LIlistas, etc?
• Há marcas legado HTML ( <b>, <i>, <center>, <font>) usado?
• O site usa a menor quantidade de marcação possível?
• As informações de estilo são externalizadas para arquivos CSS?
• Todo o Javascript é externalizado? incluindo manipuladores de eventos?
• Os nomes das classes CSS referem-se à função na página ( img-caption) e não ao formulário ( bold-red) ou ao conteúdo ( pink-elephant)?
• As imagens estão no formato apropriado (PNG ou JPEG, dependendo do tipo)?
• Foram utilizadas versões minimizadas das bibliotecas Javascript?
• Como opção, todos os arquivos Javascript e CSS desenvolvidos localmente foram minimizados?
• O HTML / CSS valida?
• O YSlow (ou similar) foi usado para verificar / otimizar o desempenho?
• (principalmente) [SEO] O site está acessível com o Javascript desativado?
• [SEO] O conteúdo mais relevante é encontrado na parte superior do HTML?

Um dos elementos importantes de um bom estilo em HTML é o aprimoramento progressivo . Isso significa que o layout HTML ficará bom mesmo sem CSS ou JavaScript. Então, depois que o JS / CSS for processado, ele ficará melhor (por exemplo, o <select>menu suspenso HTML à moda antiga será animado).

Isso também tem a ver com a marcação não intrusiva. Em vez de <font style="color:red;font-size:16pt">Hello</font>um usaria <div class="red-colored-big-fond">Hello</div>.

Mesmo com JavaScript. Em vez de <button onclick="javascript:alert('a');">Clickme</button>um, especifique uma classe / ID de botão e o direcione a partir do JavaScript. Também facilita a manutenção do seu código de marcação.

Valide que a menor quantidade de marcação é usada para realizar a tarefa. Verifique se a marcação também é semântica, não use quando uma tag fizer a mesma coisa e forneça mais informações. Valide que as extensões não estão sendo transformadas em elementos de bloco e vice-versa.

Além disso, alex traz um ótimo ponto de forma indireta. Certifique-se de que ninguém use nomes de classe como "fonte vermelha-grande-de-cor-grande", porque aproximadamente 20 segundos depois de implantado para uso real, alguém vai alterá-lo para uma pequena fonte azul. Eu realmente vi esse CSS:

.arial12pt { font-family: Verdana; font-size: 8pt; }

Tudo na sua marcação deve descrever o que é a página, não a aparência dela. Definitivamente, concordo com aprimoramentos progressivos, mas de uma maneira indireta. A página não tem requisitos para procurar algo parecido com o CSS e sem ele. Não tente fazer com que pareçam iguais, porque você acabará voltando ao terreno da mesa e ao spacer.gif.

No que diz respeito ao HTML, sempre faço questão de ter hierarquias e recuo nos meus arquivos. Por exemplo, se eu tiver um monte de divs:

<div id="content">
   <div id="post">
     <div class="title">
       Blah Blah Title
     </div>
   </div>
</div>

Suponho que isso seja bastante óbvio para a maioria dos que cria layouts e modelos, mas, na maioria das vezes, apenas vejo HTML ilegível que não possui hierarquia estrutural, dificultando a leitura para outra pessoa. Eu acho que vindo de uma formação mais em CS, isso é algo que fica na minha mente. O mesmo vale para CSS também. Digamos que você esteja criando uma div:

#whatever{
    background-image: url('blah.gif');
    color: #FFF000;
}

O recuo facilita muito a leitura rápida quando você está acostumado a outro idioma misturado como PHP / Ruby / Whatever. Novamente, depende de como você trabalha melhor, mas quando outras pessoas leem meu HTML, gosto de torná-lo realmente organizado :).

Além disso, como dito acima, é sempre uma boa idéia nomear suas classes CSS e identifica nomes relevantes para o seu layout, especialmente quando fica peludo (como nomear variáveis ​​e métodos em outros idiomas). Outra coisa a observar é o temido "palpite e verificação" de margens, preenchimentos e outros problemas de alinhamento. Algo que muitas vezes tento evitar é colocar números negativos em minhas margens e preenchimentos. Pode ficar confuso se você não fez o layout por conta própria e se quiser voltar a modificá-lo mais tarde e modificá-lo, poderá ser necessário revisá-lo. Na minha opinião, é sempre uma boa idéia não tentar nada hokey ou "kludgy" em CSS, mesmo que pareça bom; geralmente há uma maneira melhor de fazê-lo, mesmo se você precisar reestruturar seu CSS!

Para Javascript, eu sempre gostaria que ele validasse com JSLint, posso pensar em tantos bugs que JSLint captura que não usá-lo é apenas uma loucura.

Me deparei com este documento de normas que eu mais gostava. Também ecoarei o que foi dito sobre aprimoramento progressivo. Em geral, se alguém escrever o HTML / CSS, você poderá examiná-lo mais tarde na linha e surpreender-se agradavelmente com o quão ruim é a marcação e poderá fazer ajustes simples no estilo com facilidade e eficiência.