Guia de estilo JavaScript
Sempre use as mesmas convenções de codificação para todos os seus projetos JavaScript.
Convenções de codificação JavaScript
Convenções de codificação são diretrizes de estilo para programação . Normalmente cobrem:
- Regras de nomenclatura e declaração para variáveis e funções.
- Regras para o uso de espaço em branco, recuo e comentários.
- Práticas e princípios de programação
As convenções de codificação garantem a qualidade :
- Melhora a legibilidade do código
- Facilite a manutenção do código
As convenções de codificação podem ser regras documentadas para as equipes seguirem ou apenas ser sua prática de codificação individual.
Esta página descreve as convenções gerais de código JavaScript usadas pelo W3Schools.
Você também deve ler o próximo capítulo "Práticas recomendadas" e aprender como evitar armadilhas de codificação.
Nomes de Variáveis
Na W3schools usamos camelCase para nomes de identificadores (variáveis e funções).
Todos os nomes começam com uma letra .
Na parte inferior desta página, você encontrará uma discussão mais ampla sobre regras de nomenclatura.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);
Espaços ao redor dos operadores
Sempre coloque espaços ao redor dos operadores ( = + - * / ), e depois das vírgulas:
Exemplos:
let x = y + z;
const myArray = ["Volvo", "Saab",
"Fiat"];
Recuo do código
Sempre use 2 espaços para recuo de blocos de código:
Funções:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Não use tabulações (tabuladores) para recuo. Diferentes editores interpretam as guias de maneira diferente.
Regras de declaração
Regras gerais para declarações simples:
- Sempre termine uma instrução simples com um ponto e vírgula.
Exemplos:
const cars = ["Volvo", "Saab",
"Fiat"];
const person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};
Regras gerais para instruções complexas (compostas):
- Coloque o suporte de abertura no final da primeira linha.
- Use um espaço antes do suporte de abertura.
- Coloque o colchete de fechamento em uma nova linha, sem espaços à esquerda.
- Não termine uma instrução complexa com um ponto e vírgula.
Funções:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Rotações:
for (let i = 0; i < 5; i++) {
x += i;
}
Condicionais:
if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}
Regras do objeto
Regras gerais para definições de objetos:
- Coloque o colchete de abertura na mesma linha que o nome do objeto.
- Use dois pontos mais um espaço entre cada propriedade e seu valor.
- Use aspas em torno de valores de string, não em torno de valores numéricos.
- Não adicione uma vírgula após o último par propriedade-valor.
- Coloque o colchete de fechamento em uma nova linha, sem espaços à esquerda.
- Sempre termine uma definição de objeto com um ponto e vírgula.
Exemplo
const person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};
Objetos curtos podem ser escritos compactados, em uma linha, usando espaços apenas entre propriedades, assim:
const person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};
Comprimento da linha < 80
Para facilitar a leitura, evite linhas com mais de 80 caracteres.
Se uma instrução JavaScript não couber em uma linha, o melhor lugar para quebrá-la é após um operador ou uma vírgula.
Exemplo
document.getElementById("demo").innerHTML =
"Hello Dolly.";
Convenções de nomenclatura
Sempre use a mesma convenção de nomenclatura para todo o seu código. Por exemplo:
- Nomes de variáveis e funções escritos como camelCase
- Variáveis globais escritas em MAIÚSCULAS (não temos, mas é bastante comum)
- Constantes (como PI) escritas em MAIÚSCULAS
Você deve usar hyp- hens , camelCase ou under_scores em nomes de variáveis?
Esta é uma questão que os programadores costumam discutir. A resposta depende de quem você pergunta:
Hífens em HTML e CSS:
Os atributos HTML5 podem começar com dados (quantidade de dados, preço de dados).
CSS usa hífens em nomes de propriedades (tamanho da fonte).
Hífens podem ser confundidos com tentativas de subtração. Hífens não são permitidos em nomes JavaScript.
Sublinhados:
Muitos programadores preferem usar sublinhados (date_of_birth), especialmente em bancos de dados SQL.
Os sublinhados são frequentemente usados na documentação do PHP.
Pascal Case:
PascalCase é frequentemente preferido por programadores C.
camelCase:
camelCase é usado pelo próprio JavaScript, pelo jQuery e por outras bibliotecas JavaScript.
Não comece nomes com um sinal $. Isso o colocará em conflito com muitos nomes de bibliotecas JavaScript.
Carregando JavaScript em HTML
Use uma sintaxe simples para carregar scripts externos (o atributo type não é necessário):
<script src="myscript.js"></script>
Acessando elementos HTML
Uma consequência do uso de estilos HTML "desarrumados" pode resultar em erros de JavaScript.
Essas duas instruções JavaScript produzirão resultados diferentes:
const obj = getElementById("Demo")
const obj = getElementById("demo")
Se possível, use a mesma convenção de nomenclatura (como JavaScript) em HTML.
Visite o Guia de Estilo HTML .
Extensões de arquivo
Os arquivos HTML devem ter a extensão .html ( é permitido .htm ).
Os arquivos CSS devem ter uma extensão .css .
Os arquivos JavaScript devem ter uma extensão .js .
Usar nomes de arquivo em minúsculas
A maioria dos servidores web (Apache, Unix) diferencia maiúsculas de minúsculas sobre nomes de arquivos:
london.jpg não pode ser acessado como London.jpg.
Outros servidores web (Microsoft, IIS) não diferenciam maiúsculas de minúsculas:
london.jpg pode ser acessado como London.jpg ou london.jpg.
Se você usar uma mistura de maiúsculas e minúsculas, precisará ser extremamente consistente.
Se você passar de um servidor que não diferencia maiúsculas de minúsculas para um servidor que diferencia maiúsculas de minúsculas, até mesmo pequenos erros podem prejudicar seu site.
Para evitar esses problemas, sempre use nomes de arquivo em letras minúsculas (se possível).
Desempenho
Convenções de codificação não são usadas por computadores. A maioria das regras tem pouco impacto na execução dos programas.
Recuo e espaços extras não são significativos em scripts pequenos.
Para código em desenvolvimento, a legibilidade deve ser preferida. Scripts de produção maiores devem ser reduzidos.