Desenvolvimento

25 abr, 2018

Descomplicando o Google JavaScript Style Guide

Publicidade

Programadores experientes já sabem e iniciantes saberão em breve que códigos sem padrão ou padronizados com regras que somente quem escreveu conhece, são um problema de produtividade, legibilidade e podem até mesmo gerar bugs. Sim, um código escrito porcamente pode fazer com que o programador deixe passar detalhes importantes.

Tendo isso em vista, algumas empresas e instituições lançaram style guides para nós e hoje falaremos do Google JavaScript Style Guides.

O Google não é o único a publicar um “manual” deste tipo, o style guide da Airbnb para JavaScript também é muito famoso e existem muitos outros pela internet. Mas vamos deixar de papo e vamos a algumas regras que achei extremamente pertinentes para programadores de quaisquer níveis.

Nome de arquivos

Nomes de arquivos devem ser sempre em caixa baixa e podem conter undescores ( _ )ou dashes ( – ), porém não é bom misturar os dois. Escolha um padrão e siga por todo o projeto. Os arquivos devem ter a extensão .js.

new-project.js // isso é bom
new_project.js // isso é bom
new_drugstore-project.js // isso é ruim
newDrugstoreProject.js // isso é ruim

Importante: o enconding dos arquivos deve ser UTF-8

Indentação

Os códigos devem ser indentados usando-se dois espaços a cada ‘nível’ de código. A maioria dos editores de código atualmente permite a mudança de tabs para espaços e também a quantidade de espaços.

// ruim
function helloWorld() {
∙∙∙∙console.log('Olá a todos!');
}
// bom
function helloWorld() {
∙∙console.log('Olá a todos');
}

Braces (Chaves)

Chaves são obrigatórias em estruturas de controle if, else, for, do, while e devem ser usados mesmo que as instruções contenham apenas uma linha de código.

// errado
if(something() === 123)
  doSomething();
// certo
if(something() === 123) {
  doSomething();
}

Exceção: um if que tem uma condição curta e que cabe em apenas uma linha pode omitir as chaves se isso melhorar a legibilidade do código.

if(something()) return 'Olá';

Blocos de código não vazios

Os blocos de código não vazios seguem o estilo Kernighan and Ritchie, conhecido também como ‘Egyptian Brackets’.

Sempre existiu a brincadeira do “Que tipo de programador você é?”

Egyption Brackets? Why?
// Egyptian Brackets
if(true) {
}
if(true)
{
}

Além disso, algumas outras regras devem ser seguidas.

  • Nenhuma quebra de linha antes de abrir chaves
  • Uma quebra de linha após abrir as chaves
  • Uma quebra de linha antes de fechar as chaves
  • Uma quebra de linha após fechar chaves (exceção para quando há else, catch ou while, por exemplo)
if(algo) {
  try {
    doSomething();
  } catch(err) {
    onError();
  }
}

Ponto e vírgula são obrigatórios

Sempre use ponto e vírgula (semicolon) ao término de suas declarações. Apesar do código não falhar se não usarmos o guia, recomenda-se que SEMPRE usemos ao fim de cada declaração. As exceções são declarações de classes ou funções.

// errado
function waitExample() {
  setTimeout(() => {
    console.log(olá)
  }, 3000)
}
// certo
function waitExample() {
  setTimeout(() => {
    console.log(olá);
  }, 3000);
}

Variáveis

Use let ou const

Declare todas suas variáveis com let ou const. Use const como padrão, a não ser que sua variável precise ser atribuída novamente. Não devemos usar var em nenhuma ocasião.

// ruim
var counter = 0;
// bom
let counter = 0;

Nome de variáveis

Use nomes significativos em inglês e usando lower camelCase, dê nome aos bois. Use variáveis com nomes que representam exatamente o que elas armazenam.

// Certos
priceCountReader      // Sem abreviação.
numErrors             // "num" é abreviação, mas é muito difundida.
numDnsConnections     // A maioria das pessoas conhece "DNS".
// Errados
n                     // Sem significado.
nErr                  // Abreviação ambígua.
wgcConnections        // Somente seu grupo pode saber o significado.
pcReader              // Muita coisa pode ser abreviada como "pc".
cstmrId               // Remove letras internas da palavra.
kSecondsPerDay        // Não use notação húngara.

Constantes

Constantes devem ser nomeadas EM_CAIXA_ALTA e as palavras devem ser separadas por underscores.

// certo
const EULER_NUMBER = 2,71;
// errados
const euler_number = 2,71;
const EULERNUMBER = 2,71;

Uma variável por declaração

Cada declaração de variável deve declarar apenas uma variável. Não deve-se usar uma declaração múltipla.

// certo
let a = 1;
let b = 2;
// errado
let a = 1, b = 2;

Strings

Use single quotes, não double quotes em suas strings. Se for necessário usar aspas em uma string, use uma template string.

// errado
let frase = "Olá a todos";
// certo
let frase = 'Olá a todos';
// errado
let frase = 'McDonald\u0027s';
// certo
let frase = `McDonald's`;

Use template string ao invés de concatenação

Para colocar o valor de uma variável em uma string, use o string interpolation.

// errado
let helloWorld = 'Meu nome é ' + name + ' e tenho ' + age + ' anos';
// certo
let helloWorld = `Meu nome é ${name} e tenho ${age} anos`;

Use Arrow Functions

Arrow functions tornam o código mais conciso, legível e ainda resolvem diversas dificuldades com o this.

// Errado
[1, 2, 3].map(function(elemento) {
 const multiplicador = elemento * 2;
 return elemento * multiplicador;
});
// Certo
[1, 2, 3].map((elemento) => {
  const multiplicador = elemento * 2;
  return elemento * multiplicador;
});

Notas finais

A lista de instruções é bem longa e pode ser encontrada aqui.

Este artigo foi inspirado em um artigo que li em inglês e pode ser encontrado aqui.

Tudo isto não é obrigatório, mas são recomendações interessantes de um gigante da tecnologia, e qualquer padronização facilita bastante nossa vida no dia a dia. Imagine dar suporte a um código que não segue absolutamente nenhum padrão, certo?

Também existe a especificação de JavaScript da Airbnb; em breve falarei sobre ela também.

Obrigado!