Formatting Standards — Clean Code

Format kode itu bukan soal estetika — ia mempengaruhi kecepatan membaca dan kualitas diff saat review. Tim yang konsisten formatnya menghabiskan lebih sedikit e

Format kode itu bukan soal estetika — ia mempengaruhi kecepatan membaca dan kualitas diff saat review. Tim yang konsisten formatnya menghabiskan lebih sedikit energi untuk hal-hal kecil dan lebih fokus ke logic.

Mengapa formatting penting?

  1. Membaca itu 80% kerja developer — format yang baik mempercepat scan mata.
  2. Diff yang bersih — saat hanya 1 baris berubah, review cepat. Saat reformat masif campur dengan logic, review jadi lambat dan rawan bug lolos.
  3. Muscle memory tim — konsistensi membuat seluruh codebase terasa seperti ditulis satu orang.

1. Vertical Density — kelompokkan logika yang terkait

// BURUK: semua menempel, sulit menemukan batas
function processOrder(order) {
  const user = getUser(order.userId);
  validateUser(user);
  const items = order.items;
  const subtotal = items.reduce((s, i) => s + i.price, 0);
  const tax = subtotal * 0.11;
  const total = subtotal + tax;
  saveOrder({ ...order, total });
  sendEmail(user.email, total);
}

// BERSIH: blank line memisahkan fase
function processOrder(order) {
  const user = getUser(order.userId);
  validateUser(user);

  const items = order.items;
  const subtotal = items.reduce((s, i) => s + i.price, 0);
  const tax = subtotal * 0.11;
  const total = subtotal + tax;

  saveOrder({ ...order, total });
  sendEmail(user.email, total);
}

Aturan rasa: satu ide → satu paragraf. Blank line = "fase baru dimulai".

2. Vertical Openness — jangan terlalu padat juga

Tapi jangan berlebihan. Fungsi 3 baris dengan 2 blank line terasa tercerai-berai. Aturan: blank line antara kelompok logika, bukan di setiap baris.

3. Horizontal Line Length — kapan wrap?

Kebanyakan tim pakai 80–120 karakter. Kenapa?

// BURUK: panjang > 140 karakter, harus scroll
const discountedPrice = originalPrice - (originalPrice * (customer.membershipLevel === "gold" ? 0.2 : customer.membershipLevel === "silver" ? 0.1 : 0));

// BERSIH: wrap di operator, pakai variabel sementara
const discountRate =
  customer.membershipLevel === "gold" ? 0.2 :
  customer.membershipLevel === "silver" ? 0.1 : 0;
const discountedPrice = originalPrice - (originalPrice * discountRate);

4. Indentation — konsistensi > pilihan

Tab vs 2-space vs 4-space — tidak ada yang paling benar secara universal. Yang penting: satu codebase, satu aturan. Campur-campur = diff berantakan.

5. Nama file & struktur folder

// BURUK: campur-aduk
src/
  user.js
  UserProfile.jsx
  user_service.js
  user-repo.ts

// BERSIH: konvensi konsisten
src/
  user/
    User.ts
    UserProfile.tsx
    userService.ts
    userRepository.ts

Pilih satu style (camelCase, kebab-case, PascalCase untuk component) dan taati.

Otomatisasi: biarkan tool yang ngurus

Formatting manual = buang waktu dan error-prone. Setiap bahasa punya formatter:

Bahasa Tool Command
JS/TS Prettier npx prettier --write .
JS/TS ESLint (linting) npx eslint --fix .
PHP Laravel Pint / PHP CS Fixer ./vendor/bin/pint
Go gofmt (built-in) gofmt -w .
Python Black, Ruff black . / ruff format .

Git hook untuk memaksa format:

# package.json
{
  "scripts": {
    "format": "prettier --write ."
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,ts,jsx,tsx}": ["prettier --write", "eslint --fix"]
  }
}

Setelah ini terpasang, tidak ada lagi debat "kurung kurawal baris baru atau tidak?" di PR. Tool yang putuskan.

Team style guide: Tulis satu file STYLE.md di root repo dengan keputusan tim:

Semua aturan yang tidak tercakup formatter, tulis di sini. Satu sumber kebenaran.

Prinsip akhir:

"Kode yang konsisten terasa seperti ditulis oleh satu programmer, bukan lima." — Uncle Bob

Format bukan soal benar/salah. Ia soal menghormati pembaca berikutnya (termasuk dirimu 6 bulan lagi).

🎭 Analogi sehari-hari

Formatting itu kayak layout buku majalah. Buku yang ditulis konsisten — heading sama, font sama, margin sama, jeda paragraf sama — gampang dibaca cepat, mata gak capek. Buku yang campuran — bab 1 pakai heading besar tengah, bab 2 heading kecil kiri, font sans-serif lalu serif, margin acak — bikin pembaca AWARE ke layout (distraksi) bukan ISI (yang penting). Format kode konsisten = pembaca fokus ke logic, bukan ke "kenapa formatting beda di sini?". Modern era: format DEBATE udah selesai — pakai automated formatter (Prettier, Pint, gofmt). Diskusi tab-vs-spaces di 2026 = waste of time. Configure once, format otomatis di pre-commit hook, beresin.

⚠️ Jebakan yang sering ditemui

Setup Modern Standar

// package.json
{
  "scripts": {
    "format": "prettier --write ."
  },
  "lint-staged": {
    "*.{js,ts,jsx,tsx}": ["prettier --write", "eslint --fix"]
  }
}

// .prettierrc
{
  "semi": false,
  "singleQuote": true,
  "tabWidth": 2,
  "printWidth": 100
}

# .git/hooks/pre-commit (atau pakai Husky)
npx lint-staged

Setup once = gak ada lagi debate format di PR.

Bahasa Lain

🎯 Format wars — skip atau ikut?

  • Bahasa punya official formatter (Go, Rust) → 100% pakai, no debate
  • Punya tool standar industri (Prettier untuk JS) → adopt
  • Tim baru tanpa kebijakan → vote sekali di kickoff, dokumentasiin
  • Project legacy + 100% format aneh → ONE commit "format only" biar standar
  • Style argument di PR → REJECT, pasang tool, automate
  • Diff PR penuh format change → setup pre-commit hook, gak repeat

Aturan: format = automated. Manusia gak boleh manual format kecuali tool gak handle (rare).

TL;DR: Formatting standar = automated dengan tool (Prettier/Pint/gofmt/Black). Setup once: config file + pre-commit hook + lint-staged. Format DEBATE udah selesai di 2026 — pakai default tool, dokumentasi style guide untuk yang gak tercakup tool. JANGAN mix format manual + automated. JANGAN commit format + logic bareng (pisah). Konsistensi > preferensi pribadi.

Yang akan kamu pelajari