Formatar JavaScript

O código formatado

Aplicar o formatador ao JavaScript minificado acima produz:

const calculateTotal = (items, discount) => {
  let total = 0;
  for (const item of items) {
    total += item.price * item.quantity;
  }
  if (discount > 0) {
    total = total * (1 - discount / 100);
  }
  return Math.round(total * 100) / 100;
};

const formatCurrency = (amount) =>
  new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(amount);

async function fetchProducts(category) {
  const response = await fetch(`/api/products?category=${category}`);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  const data = await response.json();
  return data.products
    .filter((p) => p.inStock)
    .sort((a, b) => a.price - b.price);
}

export { calculateTotal, formatCurrency, fetchProducts };

Cada statement fica na sua própria linha. Corpos de arrow functions são quebrados em várias linhas quando passam da largura de impressão (print width). Trailing commas são adicionadas a construções multilinha para diffs mais limpos.

Por que formatar JavaScript importa

JavaScript sem formatação é um peso para manutenção. Um one-liner minificado funciona quando você escreve, mas vira algo ilegível no momento em que outra pessoa precisa alterar. A formatação deixa várias coisas mais rápidas:

Code review. Uma pessoa revisando consegue conferir a lógica da função, o destructuring dos argumentos e o fluxo de controle de forma independente quando cada statement está na sua própria linha. Uma função de uma linha só exige analisar mentalmente a string inteira para verificar qualquer parte dela.

Debugging. Quando uma função retorna resultados errados, você normalmente isola o problema adicionando console.log ou comentando linhas. Com o código bem formatado, esse processo é direto.

Diffs em pull requests. Uma mudança em uma condição deveria aparecer como uma única linha alterada no diff. Em um arquivo minificado, qualquer mudança toca a linha inteira, deixando o diff inútil para revisão.

Decisões de estilo do Prettier

O formatador usa os defaults opinativos do Prettier. Eles não são configuráveis nesta ferramenta, mas cobrem as convenções mais comuns:

Ponto e vírgula (semicolons): sempre adicionado. Isso evita bugs de ASI (automatic semicolon insertion) que são difíceis de depurar.

Aspas (quotes): aspas duplas para strings. Este é o default do Prettier e evita escapes quando as strings contêm apóstrofos.

Trailing commas: adicionadas a arrays, objetos e parâmetros de função multilinha. Isso gera diffs de git mais limpos, porque o último elemento pode mudar sem adicionar vírgula na linha anterior.

Indentação: 2 espaços. Esta é a convenção mais comum em projetos JavaScript e corresponde ao default da maioria dos linters e editores.

Largura de impressão (print width): 80 caracteres. Linhas que passam disso são quebradas em pontos lógicos (depois de arrows, antes de operadores, nas fronteiras de argumentos).

Quando não usar o Prettier

O Prettier é um formatador de código, não um linter. Ele não encontra bugs, não impõe boas práticas nem alerta sobre variáveis não usadas. Use o ESLint para isso. O Prettier também não organiza o código: ele não move funções entre arquivos, não reordena imports (a menos que configurado com um plugin) nem reestrutura o seu sistema de módulos. Alguns estilos de código são genuinamente melhores que os defaults do Prettier para casos específicos: tabs para indentação, aspas simples, sem ponto e vírgula. Se o seu projeto já tem um estilo estabelecido diferente dos defaults do Prettier, configure o Prettier de acordo ou use outro formatador.