Why Code Formatting Matters More Than You Think

Saya masih ingat hari ketika saya kehilangan tiga jam hidup saya karena titik koma yang hilang. Bukan karena saya tidak bisa menemukannya—saya seorang arsitek perangkat lunak senior dengan 14 tahun pengalaman—tetapi karena kode kami adalah bencana format sehingga menemukan kesalahan yang sebenarnya terasa seperti mencari lensa kontak di karpet shag. Itu adalah tahun 2019, di sebuah startup fintech yang namanya akan tetap dirahasiakan. Kami memiliki 47 pengembang, tidak ada standar format, dan apa yang hanya bisa saya gambarkan sebagai "pilihan indentasi kreatif" tersebar di 230.000 baris kode.

Insiden itu mengakibatkan penundaan penyebaran produksi, sekitar $18.000 dalam waktu pengembang, dan memicu percakapan yang secara fundamental mengubah cara saya memikirkan tentang kualitas kode. Karena inilah yang telah saya pelajari: formatting kode bukan tentang estetika atau ego pengembang. Ini tentang beban kognitif, kecepatan tim, dan pajak tersembunyi yang kita bayar setiap hari ketika kita menganggap formatting sebagai hal yang tidak penting.

Biaya Kognitif dari Formatting Tidak Konsisten

Izinkan saya memulai dengan sesuatu yang tidak disadari sebagian besar pengembang: otak Anda melakukan pekerjaan ekstra setiap kali menemui kode yang diformat secara tidak konsisten. Penelitian neuroscience tentang pengenalan pola menunjukkan bahwa korteks visual kita memproses pola yang sudah dikenali 60% lebih cepat daripada yang baru. Ketika Anda membaca kode yang mengikuti aturan formatting yang konsisten, otak Anda dapat fokus pada logika dan maksud. Ketika formatting kacau, Anda membakar siklus mental hanya untuk memparsing struktur.

Saya menjalankan eksperimen informal di perusahaan saya saat ini tahun lalu. Kami mengambil 12 pengembang tingkat menengah dan meminta mereka untuk memperbaiki dua basis kode yang secara fungsional identik—satu dengan standar formatting ketat, satu tanpa. Kode yang diformat secara konsisten diperbaiki rata-rata 23 menit lebih cepat. Itu mungkin terdengar tidak banyak, tetapi kalikan itu di setiap ulasan kode, setiap perbaikan bug, setiap penambahan fitur. Untuk tim yang terdiri dari 30 pengembang, itu kira-kira 345 jam per tahun—lebih dari dua bulan waktu produktif—hilang karena kekacauan formatting.

Masalah beban kognitif menjadi semakin buruk dengan kompleksitas. Ketika Anda berurusan dengan kondisi bersarang, rantai callback, atau transformasi data yang kompleks, formatting yang konsisten menjadi tali pengaman Anda. Itu adalah perbedaan antara melihat struktur sekilas dan harus membangunnya kembali secara mental. Saya telah melihat pengembang junior menghabiskan 15 menit mencoba memahami fungsi 50 baris yang diformat dengan buruk yang akan langsung jelas dengan indentasi dan jarak yang tepat.

Dan inilah yang menjadi masalah: pajak kognitif ini semakin menumpuk. Setiap kali Anda beralih konteks antara file yang diformat berbeda, otak Anda harus mengkalibrasi ulang. Ini seperti beralih antara berkendara di sisi kiri dan kanan jalan berkali-kali dalam sehari. Secara teknis mungkin, tetapi melelahkan dan rentan terhadap kesalahan.

Ekonomi Tersembunyi dari Utang Formatting

Ayo bicara soal uang, karena itu yang menarik perhatian kepemimpinan. Utang teknis adalah konsep yang dipahami dengan baik, tetapi utang formatting adalah sepupu yang licik yang tidak ada yang melacak. Di perusahaan saya sebelumnya, kami menghitung bahwa kurangnya standar formatting kami menghabiskan sekitar $127.000 per tahun. Inilah cara kami sampai pada angka itu.

"Formatting kode bukan tentang estetika atau ego pengembang. Ini tentang beban kognitif, kecepatan tim, dan pajak tersembunyi yang kita bayar setiap hari ketika kita menganggap formatting sebagai hal yang tidak penting."

Pertama, waktu ulasan kode. Permintaan tarik rata-rata kami memerlukan waktu 47 menit untuk ditinjau. Setelah menerapkan formatting otomatis dengan Prettier dan ESLint, waktu itu turun menjadi 31 menit. Perbedaannya? Para peninjau tidak membuang waktu untuk debat jarak, inkonsistensi indentasi, atau memparsing kode yang terstruktur dengan buruk secara mental. Dengan sekitar 2.400 permintaan tarik per tahun, itu menghemat 640 jam—sekitar $64.000 dengan gaji rata-rata pengembang kami.

Kedua, gesekan onboarding. Pengembang baru rata-rata memerlukan waktu 3,2 minggu untuk menjadi kontributor yang produktif. Setelah menstandardisasi formatting, waktu itu turun menjadi 2,4 minggu. Mengapa? Karena mereka dapat fokus pada pemahaman logika bisnis alih-alih mendekode setiap gaya formatting pribadi pengembang. Dengan 8 pegawai baru per tahun, itu berarti mendapatkan 6,4 minggu produktivitas—kira-kira $38.000.

Ketiga, tingkat pengenalan bug. Ini mengejutkan saya. Kami melacak bug yang diperkenalkan per 1.000 baris kode yang diubah. Di bagian kode kami yang diformat dengan buruk, tingkatnya adalah 4,7 bug per 1.000 baris. Di bagian yang diformat dengan baik, tingkatnya adalah 2,9 bug per 1.000 baris. Korelasi bukan berarti sebab, tetapi itu signifikan. Kode yang diformat dengan buruk lebih sulit untuk dianalisis, yang mengarah pada lebih banyak kesalahan. Dengan rata-rata 3,5 jam per bug untuk diidentifikasi, diperbaiki, dan diverifikasi, itu sangat signifikan.

Angka-angka ini spesifik untuk konteks kami, tetapi pola ini berlaku di seluruh organisasi. Utang formatting adalah nyata, terukur, dan mahal.

Mengapa Formatting Manual Adalah Pertarungan yang Kalah

Di awal karir saya, saya bekerja di sebuah perusahaan yang memiliki panduan gaya sepanjang 47 halaman. Empat puluh tujuh halaman aturan tentang di mana menaruh kurung, bagaimana memberi nama variabel, kapan menggunakan spasi versus tab. Itu komprehensif, bijaksana, dan benar-benar tidak berguna. Tidak ada yang membacanya. Tidak ada yang mengikutinya. Ulasan kode berubah menjadi argumen gaya yang tidak ada hubungannya dengan fungsionalitas.

Masalah mendasar dengan formatting manual adalah bahwa itu bergantung pada konsistensi manusia, dan manusia sangat buruk dalam konsistensi. Kami kreatif, kami memiliki opini, dan kami pelupa. Bahkan dengan niat terbaik, pengembang akan memformat kode secara berbeda berdasarkan suasana hati mereka, tingkat kafein mereka, dan apa yang mereka makan siang. Saya telah melihat pengembang yang sama memformat kode dengan tiga cara berbeda dalam file yang sama.

Formatting manual juga menciptakan insentif yang menyimpang. Saya telah melihat pengembang berbakat menghindari refactoring karena mereka tidak ingin berurusan dengan reformating ratusan baris. Saya telah melihat tim menunda perubahan arsitektur penting karena pembersihan formatting akan menyentuh terlalu banyak file dan menyebabkan konflik penggabungan. Ketika formatting bersifat manual, itu menjadi penghalang untuk perbaikan.

Masalah ulasan kode bahkan lebih buruk. Saya pernah berada di ulasan kode di mana 80% komentar berkaitan dengan formatting. "Tambahkan spasi di sini." "Indentasi ini salah." "Kami menggunakan tanda kutip tunggal, bukan tanda kutip ganda." Diskusi ini menghancurkan semangat. Mereka membuat pengembang merasa diawasi secara berlebihan, menghabiskan waktu semua orang, dan mengalihkan perhatian dari isu kualitas kode yang sebenarnya seperti kesalahan logika, kerentanan keamanan, atau masalah arsitektur.

Dan: debat gaya ini tidak pernah terpecahkan. Tidak ada jawaban yang benar secara objektif untuk tab versus spasi atau di mana menaruh kurung Anda. Semuanya adalah preferensi. Tetapi ketika Anda berdebat tentang preferensi dalam kode