Pemformatan Kode JavaScript: Alat dan Standar

Buka pull request mana pun yang setengah diff-nya berisi perubahan spasi, dan kamu akan langsung merasakan sakitnya. Inkonsistensi pemformatan membuang waktu, mengotori code review, dan menciptakan konflik merge yang tidak ada hubungannya dengan logika. Solusinya sederhana: pilih satu standar pemformatan, otomatiskan penerapannya, dan jangan pernah pikirkan lagi.

Panduan ini membahas alat dan standar yang menjadikan pemformatan JavaScript sebagai masalah yang sudah terpecahkan.

Mengapa Pemformatan yang Konsisten Itu Penting

Pemformatan bukan soal estetika — ini soal kecepatan tim. Ketika setiap developer menggunakan indentasi, penempatan kurung, dan panjang baris yang berbeda, tiga hal terjadi:

Code review melambat. Reviewer menghabiskan energi mental untuk mencerna pemformatan yang asing alih-alih mengevaluasi logika. Fungsi yang tampilannya berbeda dari seluruh codebase menarik perhatian untuk alasan yang salah.

Konflik merge bertambah banyak. Developer A memformat ulang file dengan tab, Developer B menggunakan spasi, dan sekarang Git menunjukkan setiap baris sebagai berubah. Perbaikan bug tiga baris yang sebenarnya jadi terkubur.

Beban kognitif meningkat. Berpindah antar file dengan gaya berbeda memaksa otak untuk terus-menerus mengurai ulang struktur. Pemformatan yang konsisten memungkinkan kamu membaca kode seperti membaca prosa — matamu sudah tahu harus melihat ke mana.

Solusinya bukan berdebat soal gaya mana yang terbaik. Solusinya adalah memilih satu dan mengotomatiskannya.

Panduan Gaya JavaScript yang Populer

Sebelum memilih alat, ada baiknya memahami panduan gaya utama yang membentuk konvensi pemformatan JavaScript.

Airbnb Style Guide

Panduan gaya JavaScript yang paling banyak diadopsi. Mewajibkan titik koma, lebih memilih tanda kutip tunggal, mengharuskan koma di akhir pada konstruksi multiline, dan menggunakan indentasi 2 spasi. Konfigurasi eslint (eslint-config-airbnb) membundel ratusan aturan yang mencakup pemformatan maupun kualitas kode.

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

Standard Style

Mengambil pendekatan sebaliknya soal titik koma — tanpa titik koma, selamanya. Menggunakan indentasi 2 spasi dan tanda kutip tunggal. Paket standard menyertakan linter-nya sendiri, jadi kamu tidak memerlukan konfigurasi ESLint terpisah.

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

Google Style Guide

Mirip dengan Airbnb tetapi dengan beberapa perbedaan dalam persyaratan JSDoc dan konvensi penamaan. Menggunakan indentasi 2 spasi, mewajibkan titik koma, dan lebih memilih tanda kutip tunggal.

Setiap panduan gaya ini memiliki kelebihan dan kekurangannya masing-masing. Yang penting adalah konsistensi, bukan yang mana yang kamu pilih. Dan semakin sering, tim melewatkan perdebatan sepenuhnya dengan membiarkan Prettier yang memutuskan.

Prettier: Formatter yang Tegas

Prettier mengubah pemformatan JavaScript dengan menghilangkan sebagian besar keputusan. Prettier mem-parse kode menjadi AST (Abstract Syntax Tree) lalu mencetaknya ulang sesuai aturannya sendiri. Kamu tidak mengonfigurasi pilihan pemformatan satu per satu — cukup atur beberapa opsi tingkat tinggi dan Prettier mengurus sisanya.

Instalasi

npm install --save-dev prettier

Buat file konfigurasi .prettierrc:

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

Opsi Konfigurasi Utama

printWidth (default: 80) — Panjang baris di mana Prettier membungkus kode. Ini bukan batas mutlak — Prettier menggunakannya sebagai pedoman kapan harus memecah ekspresi ke beberapa baris. Mengaturnya ke 100 atau 120 umum dilakukan tim yang menggunakan monitor lebar.

semi (default: true) — Apakah menambahkan titik koma di akhir pernyataan. Atur ke false jika kamu lebih suka gaya Standard.

singleQuote (default: false) — Gunakan tanda kutip tunggal alih-alih tanda kutip ganda. Sebagian besar developer JavaScript lebih suka tanda kutip tunggal, menjadikan true pengaturan yang lebih umum.

trailingComma (default: "all") — Menambahkan koma di akhir di mana pun valid. Ini menghasilkan diff Git yang lebih bersih karena menambahkan item baru ke daftar hanya menampilkan satu baris yang berubah, bukan dua.

// Tanpa koma di akhir — menambahkan "d" mengubah dua baris
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// Dengan koma di akhir — menambahkan "d" mengubah satu baris
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens (default: "always") — Apakah membungkus parameter tunggal arrow function dalam tanda kurung. "always" berarti (x) => x, "avoid" berarti x => x.

Menjalankan Prettier

# Format semua file
npx prettier --write .

# Periksa tanpa memodifikasi
npx prettier --check .

# Format tipe file tertentu
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

Tambahkan file .prettierignore untuk melewati file yang di-generate:

node_modules
dist
build
coverage
*.min.js

Jika kamu bekerja dengan JavaScript yang sudah di-minify, Code Minifier kami menangani minifikasi dengan benar — jangan pernah mengedit kode yang sudah di-minify secara manual.

ESLint: Lebih dari Sekadar Pemformatan

ESLint memiliki tujuan yang berbeda dari Prettier. Sementara Prettier menangani tampilan kode, ESLint menangkap perilaku kode. Aturan ESLint terbagi dalam dua kategori:

Aturan pemformatan — indentasi, spasi, penempatan kurung. Ini tumpang tindih dengan Prettier dan umumnya harus dinonaktifkan saat menggunakan kedua alat.

Aturan kualitas kode — variabel yang tidak digunakan, kode yang tidak terjangkau, konversi tipe implisit, penanganan error yang hilang. Di sinilah ESLint bersinar.

Konfigurasi yang Direkomendasikan

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

eslint.config.js minimal:

import js from '@eslint/js';

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

Untuk proyek TypeScript, tambahkan 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,
);

Integrasi Prettier + ESLint

Menjalankan kedua alat tanpa koordinasi menciptakan konflik — aturan pemformatan ESLint bertentangan dengan output Prettier. Solusinya adalah eslint-config-prettier, yang menonaktifkan semua aturan ESLint yang berkonflik dengan 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: {
      // Hanya aturan kualitas kode di sini
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

Dengan pengaturan ini, Prettier menguasai pemformatan dan ESLint menguasai kualitas kode. Tidak ada konflik, tidak ada kebingungan.

EditorConfig untuk Konsistensi Antar Editor

Tidak semua orang di tim kamu menggunakan editor yang sama. EditorConfig menyediakan dasar yang berfungsi di VS Code, WebStorm, Vim, Sublime Text, dan sebagian besar editor lainnya.

Buat file .editorconfig di root proyek:

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 menangani hal-hal dasar — indentasi, akhir baris, spasi di akhir — sebelum Prettier berjalan. Ini mencegah masalah umum di mana developer Windows memasukkan akhir baris \r\n ke proyek berbasis Unix.

Git Hook dengan Husky dan lint-staged

Pemformatan otomatis hanya berfungsi jika benar-benar dijalankan. Mengandalkan developer untuk mengingat npx prettier --write sebelum setiap commit tidak bisa diskalakan. Git hook menyelesaikan masalah ini.

Pengaturan

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

Tambahkan ke package.json:

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

Perbarui hook pre-commit Husky (.husky/pre-commit):

npx lint-staged

Sekarang setiap commit secara otomatis memformat file yang di-stage dan menjalankan perbaikan ESLint. Developer tidak perlu pernah memikirkan pemformatan — semuanya terjadi dengan sendirinya.

Ini adalah standar emas untuk proyek tim: Prettier memformat, ESLint menangkap bug, Husky memaksakan keduanya di setiap commit.

Debat Titik Koma

Tidak ada diskusi pemformatan JavaScript yang lengkap tanpa pertanyaan soal titik koma. Berikut jawaban praktisnya: tidak masalah, selama tim kamu konsisten.

Pro titik koma: Terminasi pernyataan yang eksplisit menghindari kasus-kasus tepi ASI (Automatic Semicolon Insertion). Panduan gaya Airbnb dan Google mewajibkannya.

Tanpa titik koma: ASI JavaScript menangani terminasi secara otomatis. Kode lebih bersih dengan lebih sedikit gangguan visual. Panduan gaya Standard menghilangkannya.

Kasus-kasus ASI yang sering diingatkan orang — seperti baris yang dimulai dengan ( atau [ — tertangkap oleh aturan no-unexpected-multiline ESLint. Dalam praktiknya, bekerja tanpa titik koma dengan linting yang tepat benar-benar aman.

Pilih satu, konfigurasi opsi semi Prettier, dan lanjutkan. Prettier akan menambahkan atau menghapusnya secara konsisten bagaimanapun pilihanmu.

Tab vs Spasi di JavaScript

Ekosistem JavaScript secara dominan menggunakan spasi — khususnya, indentasi 2 spasi. Ini bukan aturan universal (Go menggunakan tab, Python menggunakan 4 spasi), tetapi di JavaScript ini adalah konvensi yang sangat kuat.

Mengapa 2 spasi? Pola callback bersarang dan metode berantai JavaScript dengan cepat menciptakan indentasi yang dalam. Dua spasi menjaga kode yang bersarang dalam tetap terbaca tanpa mendorongnya ke tepi kanan layar.

Mengapa bukan tab? Tab memungkinkan setiap developer mengatur lebar tampilannya sendiri, yang kedengarannya bagus tetapi berarti perataan kode rusak di berbagai editor. Dengan spasi, apa yang kamu lihat adalah apa yang dilihat semua orang.

Konfigurasi ini sekali di Prettier (tabWidth: 2, useTabs: false) dan EditorConfig (indent_style = space, indent_size = 2), dan selesai.

Kesalahan Pemformatan yang Umum

Arrow Function yang Tidak Konsisten

// Tidak konsisten — hindari ini
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

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

Gaya Destructuring Objek

// Terlalu rapat — sulit dibaca
const {name,email,role} = user;

// Terformat — Prettier menangani ini secara otomatis
const { name, email, role } = user;

// Multiline untuk banyak properti
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

Pengorganisasian Pernyataan Import

Prettier tidak mengurutkan import — itu urusan kualitas kode, bukan pemformatan. Gunakan eslint-plugin-import atau plugin simple-import-sort:

// Import yang terorganisir
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';

Ekspresi Ternari yang Panjang

// Tidak terbaca dalam satu baris
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettier memformat ulang menjadi multiline yang terbaca
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

Menyiapkan Proyek Baru

Berikut checklist lengkap untuk menyiapkan proyek JavaScript atau TypeScript baru:

1. Instal dependensi:

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

2. Buat .prettierrc dengan preferensi tim kamu

3. Buat .editorconfig sebagai dasar konsistensi antar editor

4. Konfigurasi ESLint hanya dengan aturan kualitas kode (tanpa aturan pemformatan)

5. Siapkan Husky + lint-staged untuk penerapan otomatis di pre-commit

6. Tambahkan script npm:

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

7. Jalankan pemformatan awal pada seluruh codebase: npm run format

8. Commit kode yang sudah diformat sebagai satu commit agar mudah dilewati di git blame dengan --ignore-rev

Pemformatan dalam Praktik

Setelah pipeline pemformatan kamu siap, pengalaman sehari-hari berubah drastis:

• Tulis kode sesukamu. Prettier memformat ulang saat menyimpan atau commit.
• Pull request hanya menampilkan perubahan logika. Tidak ada lagi gangguan spasi.
• Anggota tim baru langsung produktif. Alat-alat memaksakan standar tanpa perlu dokumen panduan gaya.
• Perdebatan soal gaya menghilang. Prettier adalah otoritasnya, bukan developer mana pun.

Ketika kamu perlu memeriksa struktur data JSON yang sedang kamu kerjakan, JSON Formatter kami memudahkan inspeksi — tempel JSON apa pun dan dapatkan pemformatan yang mudah dibaca secara instan langsung di browser.

Sumber Daya Terkait

Untuk informasi lebih lanjut tentang pemformatan kode dan alat developer:

• Code Minification Guide — Pelajari kapan dan bagaimana melakukan minifikasi JavaScript untuk produksi
• Naming Conventions in Programming — Konvensi penamaan yang konsisten adalah separuh lainnya dari kode yang mudah dibaca
• SQL Formatting Best Practices — Terapkan disiplin pemformatan yang sama pada query database kamu

Pemformatan yang konsisten adalah salah satu investasi rekayasa langka yang langsung memberikan hasil dan terus memberikan hasil. Siapkan sekali, otomatiskan, dan curahkan energimu untuk kode yang benar-benar penting.