Nosso código deve ser o mais limpo e fácil de ler possível.
Na verdade, essa é a arte da programação – pegar uma tarefa complexa e codificá-la de uma forma que seja correta e legível por humanos. Um bom estilo de código ajuda muito nisso.
Aqui está uma folha de dicas com algumas regras sugeridas (veja abaixo para mais detalhes):
Agora vamos discutir detalhadamente as regras e as razões para elas.
Não existem regras do tipo “você deve”
Nada está definido aqui. Estas são preferências de estilo, não dogmas religiosos.
Na maioria dos projetos JavaScript, as chaves são escritas no estilo “egípcio”, com a chave de abertura na mesma linha da palavra-chave correspondente – não em uma nova linha. Também deve haver um espaço antes do colchete de abertura, assim:
se (condição) {
//faça isso
// ...e isso
// ...e isso
} Uma construção de linha única, como if (condition) doSomething() , é um caso extremo importante. Devemos usar aparelho?
Aqui estão as variantes anotadas para que você possa avaliar sua legibilidade por si mesmo:
? Os iniciantes às vezes fazem isso. Ruim! Aparelhos encaracolados não são necessários:
if (n < 0) {alert(`Power ${n} não é suportado`);}? Divida em uma linha separada sem colchetes. Nunca faça isso, é fácil cometer um erro ao adicionar novas linhas:
se (n < 0)
alert(`Power ${n} não é suportado`);? Uma linha sem colchetes – aceitável, se for curta:
if (n < 0) alert(`Power ${n} não é suportado`);? A melhor variante:
se (n < 0) {
alert(`Power ${n} não é suportado`);
} Para um código muito breve, uma linha é permitida, por exemplo, if (cond) return null . Mas um bloco de código (a última variante) geralmente é mais legível.
Ninguém gosta de ler uma longa linha horizontal de código. É uma prática recomendada dividi-los.
Por exemplo:
// aspas de crase `permitem dividir a string em múltiplas linhas deixe str = ` O TC39 da ECMA International é um grupo de desenvolvedores de JavaScript, implementadores, acadêmicos e muito mais, colaborando com a comunidade para manter e evoluir a definição de JavaScript. `;
E, para instruções if :
se (
identificação === 123 &&
moonPhase === 'Waning Gibbous' &&
signo do zodíaco === 'Libra'
) {
letTheSorceryBegin();
}O comprimento máximo da linha deve ser acordado em nível de equipe. Geralmente tem 80 ou 120 caracteres.
Existem dois tipos de recuos:
Recuos horizontais: 2 ou 4 espaços.
Um recuo horizontal é feito usando 2 ou 4 espaços ou o símbolo de tabulação horizontal (tecla Tab ). Qual escolher é uma velha guerra santa. Os espaços são mais comuns hoje em dia.
Uma vantagem dos espaços sobre tabulações é que os espaços permitem configurações de recuo mais flexíveis do que o símbolo de tabulação.
Por exemplo, podemos alinhar os parâmetros com o colchete de abertura, assim:
mostrar(parâmetros,
alinhado, // preenchimento de 5 espaços à esquerda
um,
depois,
outro
) {
// ...
}Recuos verticais: linhas vazias para dividir o código em blocos lógicos.
Muitas vezes, mesmo uma única função pode ser dividida em blocos lógicos. No exemplo abaixo, a inicialização das variáveis, o loop principal e o retorno do resultado são divididos verticalmente:
função pow(x, n) {
deixe resultado = 1;
// <--
for (seja i = 0; i < n; i++) {
resultado *=x;
}
// <--
resultado de retorno;
}Insira uma nova linha extra onde ajudar a tornar o código mais legível. Não deve haver mais de nove linhas de código sem recuo vertical.
Um ponto e vírgula deve estar presente após cada instrução, mesmo que possa ser ignorado.
Existem idiomas onde o ponto e vírgula é verdadeiramente opcional e raramente é usado. Em JavaScript, porém, há casos em que uma quebra de linha não é interpretada como ponto e vírgula, deixando o código vulnerável a erros. Veja mais sobre isso no capítulo Estrutura do código.
Se você for um programador JavaScript experiente, poderá escolher um estilo de código sem ponto e vírgula, como StandardJS. Caso contrário, é melhor usar ponto e vírgula para evitar possíveis armadilhas. A maioria dos desenvolvedores coloca ponto e vírgula.
Tente evitar aninhar código com muitos níveis de profundidade.
Por exemplo, no loop, às vezes é uma boa ideia usar a diretiva continue para evitar aninhamentos extras.
Por exemplo, em vez de adicionar uma condicional if aninhada como esta:
for (seja i = 0; i < 10; i++) {
se (condição) {
... // <- mais um nível de aninhamento
}
}Podemos escrever:
for (seja i = 0; i < 10; i++) {
se (!cond) continuar;
... // <- sem nível de aninhamento extra
} Algo semelhante pode ser feito com if/else e return .
Por exemplo, duas construções abaixo são idênticas.
Opção 1:
função pow(x, n) {
se (n < 0) {
alert("Negativo 'n' não suportado");
} outro {
deixe resultado = 1;
for (seja i = 0; i < n; i++) {
resultado *=x;
}
resultado de retorno;
}
}Opção 2:
função pow(x, n) {
se (n < 0) {
alert("Negativo 'n' não suportado");
retornar;
}
deixe resultado = 1;
for (seja i = 0; i < n; i++) {
resultado *= x;
}
resultado de retorno;
} O segundo é mais legível porque o “caso especial” de n < 0 é tratado logo no início. Assim que a verificação for concluída, podemos passar para o fluxo de código “principal” sem a necessidade de aninhamentos adicionais.
Se você estiver escrevendo diversas funções “auxiliares” e o código que as utiliza, há três maneiras de organizar as funções.
Declare as funções acima do código que as utiliza:
//declarações de funções
função criarElemento() {
...
}
function setHandler(elem) {
...
}
função percorrer() {
...
}
// o código que os utiliza
deixe elem = createElement();
setHandler(elem);
percorrer();Código primeiro, depois funções
// o código que usa as funções
deixe elem = createElement();
setHandler(elem);
percorrer();
// --- funções auxiliares ---
função criarElemento() {
...
}
function setHandler(elem) {
...
}
função percorrer() {
...
}Misto: uma função é declarada onde é usada pela primeira vez.
Na maioria das vezes, a segunda variante é preferida.
Isso porque ao ler o código, primeiro queremos saber o que ele faz . Se o código for primeiro, ficará claro desde o início. Então, talvez não precisemos ler as funções, especialmente se seus nomes descrevem o que elas realmente fazem.
Um guia de estilo contém regras gerais sobre “como escrever” código, por exemplo, quais aspas usar, quantos espaços recuar, o comprimento máximo da linha, etc. Muitas coisas menores.
Quando todos os membros de uma equipe usam o mesmo guia de estilo, o código parece uniforme, independentemente de qual membro da equipe o escreveu.
É claro que uma equipe sempre pode escrever seu próprio guia de estilo, mas geralmente não há necessidade disso. Existem muitos guias existentes para você escolher.
Algumas escolhas populares:
Guia de estilo JavaScript do Google
Guia de estilo JavaScript do Airbnb
Idiomático.JS
PadrãoJS
(e muitos mais)
Se você é um desenvolvedor iniciante, comece com a folha de dicas no início deste capítulo. Depois, você pode navegar por outros guias de estilo para obter mais ideias e decidir qual você mais gosta.
Linters são ferramentas que podem verificar automaticamente o estilo do seu código e fazer sugestões de melhorias.
A melhor coisa sobre eles é que a verificação de estilo também pode encontrar alguns bugs, como erros de digitação em nomes de variáveis ou funções. Por causa desse recurso, o uso de um linter é recomendado mesmo se você não quiser se limitar a um “estilo de código” específico.
Aqui estão algumas ferramentas de linting bem conhecidas:
JSLint – um dos primeiros linters.
JSHint – mais configurações que JSLint.
ESLint – provavelmente o mais novo.
Todos eles podem fazer o trabalho. O autor usa ESLint.
A maioria dos linters são integrados a muitos editores populares: basta habilitar o plugin no editor e configurar o estilo.
Por exemplo, para ESLint você deve fazer o seguinte:
Instale o Node.js.
Instale o ESLint com o comando npm install -g eslint (npm é um instalador de pacote JavaScript).
Crie um arquivo de configuração chamado .eslintrc na raiz do seu projeto JavaScript (na pasta que contém todos os seus arquivos).
Instale/habilite o plugin do seu editor que se integra ao ESLint. A maioria dos editores tem um.
Aqui está um exemplo de arquivo .eslintrc :
{
"extends": "eslint:recomendado",
"env": {
"navegador": verdadeiro,
"nó": verdadeiro,
"es6": verdadeiro
},
"regras": {
"sem console": 0,
"recuo": 2
}
} Aqui, a diretiva "extends" indica que a configuração é baseada no conjunto de configurações “eslint:recommended”. Depois disso, especificamos o nosso.
Também é possível baixar conjuntos de regras de estilo da web e estendê-los. Consulte https://eslint.org/docs/user-guide/getting-started para obter mais detalhes sobre a instalação.
Além disso, certos IDEs possuem linting integrado, o que é conveniente, mas não tão personalizável quanto o ESLint.
Todas as regras de sintaxe descritas neste capítulo (e nos guias de estilo referenciados) visam aumentar a legibilidade do seu código. Todos eles são discutíveis.
Quando pensamos em escrever um código “melhor”, as perguntas que devemos nos fazer são: “O que torna o código mais legível e mais fácil de entender?” e “O que pode nos ajudar a evitar erros?” Estas são as principais coisas a se ter em mente ao escolher e debater estilos de código.
A leitura de guias de estilo populares permitirá que você se mantenha atualizado com as ideias mais recentes sobre tendências e práticas recomendadas de estilo de código.
importância: 4
O que há de errado com o estilo de código abaixo?
função pow(x,n)
{
deixe resultado = 1;
for(deixe i=0;i<n;i++) {resultado*=x;}
resultado de retorno;
}
deixe x=prompt("x?",''), n=prompt("n?",'')
se (n<=0)
{
alert(`Power ${n} não é suportado, insira um número inteiro maior que zero`);
}
outro
{
alerta(pow(x,n))
}Corrija isso.
Você pode observar o seguinte:
function pow(x,n) // <- sem espaço entre os argumentos
{ // <- colchete de figura em uma linha separada
deixe resultado = 1; // <- sem espaços antes ou depois =
for(let i=0;i<n;i++) {result*=x;} // <- sem espaços
// o conteúdo de {...} deve estar em uma nova linha
resultado de retorno;
}
let x=prompt("x?",''), n=prompt("n?",'') // <-- tecnicamente possível,
// mas é melhor fazer 2 linhas, também não tem espaços e falta ;
if (n<=0) // <- sem espaços dentro de (n <= 0), e deve haver uma linha extra acima dele
{ // <- colchete de figura em uma linha separada
// abaixo - linhas longas podem ser divididas em múltiplas linhas para melhorar a legibilidade
alert(`Power ${n} não é suportado, insira um número inteiro maior que zero`);
}
else // <- poderia escrever em uma única linha como "} else {"
{
alert(pow(x,n)) // sem espaços e faltando ;
}A variante fixa:
função pow(x, n) {
deixe resultado = 1;
for (seja i = 0; i < n; i++) {
resultado *=x;
}
resultado de retorno;
}
deixe x = prompt("x?", "");
deixe n = prompt("n?", "");
se (n <= 0) {
alert(`Power ${n} não é suportado,
insira um número inteiro maior que zero`);
} outro {
alerta( pow(x, n) );
}