Formattazione del Codice JavaScript: Strumenti e Standard

Apri una qualsiasi pull request in cui metà del diff è composta da modifiche agli spazi bianchi e sentirai immediatamente il problema. Le incoerenze nella formattazione fanno perdere tempo, inquinano le code review e creano conflitti di merge che non hanno nulla a che fare con la logica. La soluzione è semplice: scegli uno standard di formattazione, automatizza il rispetto delle regole e non pensarci mai più.

Questa guida illustra gli strumenti e gli standard che rendono la formattazione JavaScript un problema risolto.

Perché la Formattazione Coerente è Importante

La formattazione non è una questione estetica — è una questione di velocità del team. Quando ogni sviluppatore usa indentazione, posizionamento delle parentesi e lunghezze di riga diverse, succedono tre cose:

Le code review rallentano. I revisori spendono energia mentale a decifrare una formattazione poco familiare anziché valutare la logica. Una funzione che appare diversa da tutto il resto nel codebase attira l'attenzione per le ragioni sbagliate.

I conflitti di merge si moltiplicano. Lo sviluppatore A riformatta un file con i tab, lo sviluppatore B usa gli spazi, e ora Git mostra ogni riga come modificata. La vera correzione di tre righe finisce sepolta.

Il carico cognitivo aumenta. Passare da un file all'altro con stili diversi costringe il cervello a rianalizzare continuamente la struttura. Una formattazione coerente permette di leggere il codice come un testo scorrevole — i tuoi occhi sanno già dove guardare.

La soluzione non è discutere su quale stile sia migliore. È sceglierne uno e automatizzarlo.

Guide di Stile JavaScript Popolari

Prima di scegliere gli strumenti, è utile conoscere le principali guide di stile che hanno plasmato le convenzioni di formattazione JavaScript.

Airbnb Style Guide

La guida di stile JavaScript più adottata al mondo. Impone i punti e virgola, preferisce le virgolette singole, richiede le virgole finali nei costrutti multilinea e usa l'indentazione a 2 spazi. La configurazione eslint (eslint-config-airbnb) include centinaia di regole che coprono sia la formattazione che la qualità del codice.

// Airbnb style
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

Adotta l'approccio opposto sui punti e virgola — niente punti e virgola, mai. Usa indentazione a 2 spazi e virgolette singole. Il pacchetto standard include il proprio linter, quindi non serve una configurazione ESLint separata.

// Standard style
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Simile ad Airbnb ma con alcune differenze nei requisiti JSDoc e nelle convenzioni di denominazione. Usa indentazione a 2 spazi, richiede i punti e virgola e preferisce le virgolette singole.

Ognuna di queste guide di stile ha i suoi compromessi. L'importante è la coerenza, non quale scegli. E sempre più spesso, i team saltano il dibattito del tutto lasciando decidere a Prettier.

Prettier: Il Formatter Rigido

Prettier ha rivoluzionato la formattazione JavaScript eliminando la maggior parte delle decisioni. Analizza il codice in un AST (Abstract Syntax Tree) e lo riscrive secondo le proprie regole. Non si configurano le singole scelte di formattazione — si impostano poche opzioni di alto livello e Prettier fa il resto.

Installazione

npm install --save-dev prettier

Crea un file di configurazione .prettierrc:

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

Opzioni di Configurazione Principali

printWidth (default: 80) — La lunghezza della riga oltre la quale Prettier va a capo. Non è un limite rigido — Prettier lo usa come riferimento per decidere quando spezzare le espressioni su più righe. Impostarlo a 100 o 120 è comune per i team con monitor ampi.

semi (default: true) — Se aggiungere i punti e virgola alla fine delle istruzioni. Impostalo su false se preferisci lo stile Standard.

singleQuote (default: false) — Usa virgolette singole al posto delle doppie. La maggior parte degli sviluppatori JavaScript preferisce le virgolette singole, rendendo true l'impostazione più comune.

trailingComma (default: "all") — Aggiunge virgole finali ovunque sia valido. Questo produce diff Git più puliti perché aggiungere un nuovo elemento a un elenco mostra una sola riga modificata anziché due.

// Senza virgole finali — aggiungere "d" modifica due righe
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// Con virgole finali — aggiungere "d" modifica una riga
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens (default: "always") — Se racchiudere un singolo parametro di una arrow function tra parentesi. "always" significa (x) => x, "avoid" significa x => x.

Eseguire Prettier

# Formatta tutti i file
npx prettier --write .

# Controlla senza modificare
npx prettier --check .

# Formatta tipi di file specifici
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

Aggiungi un file .prettierignore per escludere i file generati:

node_modules
dist
build
coverage
*.min.js

Se lavori con JavaScript minificato, il nostro Code Minifier gestisce la minificazione correttamente — non modificare mai a mano il codice minificato.

ESLint: Oltre la Formattazione

ESLint ha uno scopo diverso da Prettier. Mentre Prettier si occupa dell'aspetto del codice, ESLint intercetta il comportamento del codice. Le regole ESLint si dividono in due categorie:

Regole di formattazione — indentazione, spaziatura, posizionamento delle parentesi. Queste si sovrappongono a Prettier e in genere vanno disabilitate quando si usano entrambi gli strumenti.

Regole di qualità del codice — variabili inutilizzate, codice irraggiungibile, coercizione implicita dei tipi, gestione degli errori mancante. È qui che ESLint eccelle.

Configurazione Consigliata

npm install --save-dev eslint @eslint/js

Un eslint.config.js minimale:

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

Per i progetti TypeScript, aggiungi typescript-eslint:

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Integrazione Prettier + ESLint

Eseguire entrambi gli strumenti senza coordinamento crea conflitti — le regole di formattazione di ESLint combattono l'output di Prettier. La soluzione è eslint-config-prettier, che disabilita tutte le regole ESLint in conflitto con Prettier.

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // Solo regole di qualità del codice qui
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

Con questa configurazione, Prettier gestisce la formattazione ed ESLint gestisce la qualità del codice. Nessun conflitto, nessuna confusione.

EditorConfig per la Coerenza tra Editor

Non tutti nel tuo team usano lo stesso editor. EditorConfig fornisce una base comune che funziona con VS Code, WebStorm, Vim, Sublime Text e la maggior parte degli altri editor.

Crea un file .editorconfig nella root del tuo progetto:

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

EditorConfig gestisce le basi — indentazione, fine riga, spazi finali — prima ancora che Prettier entri in azione. Questo previene il problema comune in cui uno sviluppatore Windows introduce fine riga \r\n in un progetto basato su Unix.

Git Hook con Husky e lint-staged

La formattazione automatica funziona solo se viene effettivamente eseguita. Fare affidamento sul fatto che gli sviluppatori ricordino npx prettier --write prima di ogni commit non scala. I git hook risolvono questo problema.

Configurazione

npm install --save-dev husky lint-staged
npx husky init

Aggiungi al package.json:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Aggiorna l'hook pre-commit di Husky (.husky/pre-commit):

npx lint-staged

Ora ogni commit formatta automaticamente i file in staging ed esegue le correzioni ESLint. Gli sviluppatori non devono mai pensare alla formattazione — succede e basta.

Questo è lo standard d'oro per i progetti di team: Prettier formatta, ESLint intercetta i bug, Husky li impone a ogni commit.

Il Dibattito sui Punti e Virgola

Nessuna discussione sulla formattazione JavaScript è completa senza la questione dei punti e virgola. Ecco la risposta pratica: non importa, purché il team sia coerente.

Pro punti e virgola: La terminazione esplicita delle istruzioni evita i casi limite dell'ASI (Automatic Semicolon Insertion). Le guide di stile Airbnb e Google li richiedono.

Senza punti e virgola: L'ASI di JavaScript gestisce la terminazione automaticamente. Il codice è più pulito con meno rumore visivo. La guida Standard li omette.

I casi problematici dell'ASI di cui si sente parlare — come le righe che iniziano con ( o [ — vengono intercettati dalla regola no-unexpected-multiline di ESLint. In pratica, lavorare senza punti e virgola con un linting adeguato è perfettamente sicuro.

Scegline uno, configura l'opzione semi di Prettier e vai avanti. Prettier li aggiungerà o rimuoverà in modo coerente in entrambi i casi.

Tab vs Spazi in JavaScript

L'ecosistema JavaScript usa in modo schiacciante gli spazi — nello specifico, indentazione a 2 spazi. Non è una regola universale (Go usa i tab, Python usa 4 spazi), ma in JavaScript è la convenzione dominante.

Perché 2 spazi? I pattern di callback annidati e i metodi concatenati di JavaScript creano rapidamente indentazioni profonde. Due spazi mantengono leggibile il codice profondamente annidato senza spingerlo fuori dal bordo destro dello schermo.

Perché non i tab? I tab permettono a ogni sviluppatore di impostare la propria larghezza di visualizzazione, il che sembra positivo ma significa che l'allineamento del codice si rompe tra diversi editor. Con gli spazi, ciò che vedi è ciò che vedono tutti.

Configura questo una volta in Prettier (tabWidth: 2, useTabs: false) e in EditorConfig (indent_style = space, indent_size = 2), e la questione è risolta.

Errori Comuni di Formattazione

Arrow Function Incoerenti

// Incoerente — da evitare
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// Coerente — Prettier con arrowParens: "always"
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

Stile del Destructuring degli Oggetti

// Compresso — difficile da leggere
const {name,email,role} = user;

// Formattato — Prettier lo gestisce automaticamente
const { name, email, role } = user;

// Multilinea per molte proprietà
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

Organizzazione delle Istruzioni Import

Prettier non ordina gli import — quella è una questione di qualità del codice, non di formattazione. Usa eslint-plugin-import o il plugin simple-import-sort:

// Import organizzati
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

Espressioni Ternarie Lunghe

// Illeggibile su una riga
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettier riformatta in multilinea leggibile
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

Configurare un Nuovo Progetto

Ecco una checklist completa per configurare un nuovo progetto JavaScript o TypeScript:

1. Installa le dipendenze:

   npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged
   

2. Crea .prettierrc con le preferenze del tuo team

3. Crea .editorconfig come base comune tra editor

4. Configura ESLint solo con regole di qualità del codice (nessuna regola di formattazione)

5. Configura Husky + lint-staged per l'applicazione automatica al pre-commit

6. Aggiungi script npm:

   {
     "scripts": {
       "format": "prettier --write .",
       "format:check": "prettier --check .",
       "lint": "eslint .",
       "lint:fix": "eslint --fix ."
     }
   }
   

7. Esegui la formattazione iniziale sull'intero codebase: npm run format

8. Committa il codice formattato come un singolo commit così è facile da ignorare in git blame con --ignore-rev

La Formattazione nella Pratica

Una volta configurata la pipeline di formattazione, l'esperienza quotidiana cambia radicalmente:

• Scrivi il codice come preferisci. Prettier riformatta al salvataggio o al commit.
• Le pull request mostrano solo modifiche alla logica. Niente più rumore di spazi bianchi.
• I nuovi membri del team sono produttivi immediatamente. Gli strumenti impongono gli standard senza bisogno di un documento di guida di stile.
• Le discussioni sullo stile scompaiono. Prettier è l'autorità, non il singolo sviluppatore.

Quando hai bisogno di verificare la struttura dei dati JSON con cui stai lavorando, il nostro JSON Formatter rende l'ispezione semplice — incolla qualsiasi JSON e ottieni una formattazione leggibile istantanea direttamente nel browser.

Risorse Correlate

Per approfondire la formattazione del codice e gli strumenti per sviluppatori:

• Code Minification Guide — Scopri quando e come minificare JavaScript per la produzione
• Naming Conventions in Programming — Le convenzioni di denominazione coerenti sono l'altra metà del codice leggibile
• SQL Formatting Best Practices — Applica la stessa disciplina di formattazione alle tue query di database

La formattazione coerente è uno di quegli investimenti ingegneristici rari che ripaga immediatamente e continua a ripagare nel tempo. Configurala una volta, automatizzala, e dedica le tue energie al codice che conta davvero.