Pemformatan kode seharusnya tidak diperlukan

• Di masa lalu, lingkungan pengembangan Ada sudah pernah menyelesaikan masalah pemformatan kode
• Para pengembang menangani kode dalam bentuk representasi antara (IR) DIANA, lalu melihatnya dengan pengaturan pretty-printing sesuai preferensi masing-masing
• Hingga kini masih ada inefisiensi dan perdebatan yang terus berulang terkait linter atau kebijakan pemformatan
• Workstation Rational R1000 saat itu menyediakan lingkungan dan fitur pengembangan yang inovatif
• Dari persoalan pemformatan coding, artikel ini mengusulkan gagasan untuk mengubah praktik pengembangan masa kini dengan merujuk pada pendekatan satu generasi sebelumnya

---

Perdebatan pemformatan kode – solusi dari era 1980-an

• Penulis menyebut pengalamannya dengan Mr. Paige, seorang guru ilmu komputer yang pernah ikut mengerjakan compiler Ada saat penulis masih SMA
• Ketika pada 2016 ia mengeluhkan ribetnya pengaturan tool linter dan bertanya, “kenapa kita masih harus mengalami masalah seperti ini?”, ia diperkenalkan pada pengalaman bahwa persoalan ini sebenarnya sudah diselesaikan lebih dari 40 tahun lalu

Munculnya Ada dan DIANA

• Alih-alih menyimpan source code teks, para pengembang Ada menggunakan representasi antara bernama DIANA (Descriptive Intermediate Attributed Notation for Ada)
• Setiap pengembang bisa melihat source dengan pengaturan pretty-printing miliknya sendiri sesuai gaya yang diinginkan
• Tidak ada perdebatan soal pemformatan atau isu linter, dan di editor mereka bisa langsung mengubah tree program (mirip dengan projectional editing modern)

Rational R1000 – lingkungan pengembangan perintis

• Workstation Rational R1000 memiliki berbagai fitur tingkat lanjut bawaan seperti incremental compilation, analisis statis, version control, dan debugging
• Sistem ini digunakan dalam proyek perangkat lunak penting seperti proyek pemerintah termasuk DoD, Stasiun Luar Angkasa Internasional (ISS), dan pesawat tempur F-22, serta turut berkontribusi pada lahirnya UML
• Menurut Grady Booch, R1000 adalah mesin berbasis DIANA yang tidak menyimpan source code, melainkan hanya menggunakan pretty-printing dari tree DIANA

Keunggulan pengembangan berbasis DIANA

• Tidak perlu perdebatan soal pemformatan, pengaturan linter, atau penyeragaman lingkungan editor
• Dengan akselerasi perangkat keras, sistem ini menghadirkan pengalaman pengembangan yang inovatif seperti incremental compilation, refactoring yang mudah, dan integrasi yang cepat
• Pendekatan ini berdampak penting pada efisiensi pengembangan dan pekerjaan pada sistem berskala besar

Implikasi untuk masa kini

• Akselerasi kompilasi berbasis perangkat keras kini kurang penting, tetapi penyelesaian masalah pemformatan masih tetap belum memadai
• Meskipun pendekatan utama saat ini bukan projectional editing atau lingkungan live, sudah waktunya mempertimbangkan adopsi praktik pengembangan yang lebih efisien dan minim perdebatan seperti pendekatan di masa lalu

Referensi

• Saat meneliti topik ini, penulis mengutip berbagai dokumen dan laporan teknis terkait R1000

[ndrgrd]

Setahu saya, kode yang dibagikan sudah memiliki fitur untuk diformat otomatis melalui konfigurasi yang seragam, dan sepertinya perusahaan-perusahaan juga banyak menggunakannya.

[euphcat]

Intinya bukan auto-formatting yang menjadi pokok bahasan, melainkan bahwa sejak awal pun tidak perlu ada anggapan bahwa formatting tertentu lebih unggul, atau proses membuang formatting saya sendiri lalu beradaptasi dengan formatting asing. Karena logikanya adalah menyimpan representasi perantara yang tidak terikat pada formatting, lalu melakukan pretty-printing sesuai cara yang paling nyaman bagi masing-masing pengguna.

[ndrgrd]

Yang ingin saya sampaikan adalah bahwa dengan pemformatan otomatis, kita bisa melakukan hal yang sama dalam bahasa-bahasa yang ada saat ini tanpa perlu representasi perantara, tetapi penjelasan saya memang kurang memadai.

[GN⁺]

Opini Hacker News

• Saya tidak mengerti kenapa orang begitu peduli pada pengaturan linter, ini jelas perdebatan yang tidak perlu; tinggal putuskan satu, jalankan linter otomatis, lalu selesai. Rasanya jauh lebih penting punya waktu untuk benar-benar mengerjakan software engineering. Format apa pun, kalau tim sudah memutuskan dan memakainya, dalam seminggu juga akan terbiasa.
  • Perlu dibedakan bahwa source code formatter dan program lint itu berbeda; formatter hanya merapikan tata letak kode, sedangkan linter membantu menemukan kemungkinan bug atau error di dalam kode. Beberapa alat mendukung keduanya, tetapi itu hanya detail implementasi. Untuk memahami apa itu lint, bisa merujuk ke https://en.wikipedia.org/wiki/Lint_(software).
  • Saya menghabiskan sebagian besar waktu untuk "membaca" kode, dan tata letak kode berhubungan dengan kecepatan saya membaca kode. Mungkin kita bisa terbiasa dengan tata letak yang berbeda, tetapi tidak semua tata letak sama mudahnya dibaca. Saya mengingat kode lewat pola visual, dan membaca kode dengan memecahnya berdasarkan tata letak. Ironisnya, saya punya aphantasia sehingga tidak bisa memvisualisasikan dalam pikiran, tetapi justru lebih mudah mengingat lewat petunjuk visual.
  • Beberapa pengaturan linter jelas punya kelebihan. Misalnya, memakai trailing comma pada tabel berarti saat menambah item baru di baris terakhir, cukup mengedit satu baris saja, dan diff juga jadi lebih sederhana. Jadi pilihan yang salah membuat hidup saya lebih sulit. Hal yang sama berlaku untuk daftar atau include yang diurutkan; kalau tidak diurutkan, orang selalu menambahkan di akhir sehingga merge conflict jadi sering terjadi. Seperti manfaat auto formatter, pengurutan juga harus menghemat waktu. Dan saya sensitif terhadap gaya yang tidak konsisten. Yang paling penting adalah menyeragamkan ke satu gaya saja.
  • Saya tidak terlalu peduli pada opsi-opsi detail, tetapi menurut saya pengaturan linter bersama itu penting untuk mengurangi noise yang tidak perlu saat meninjau PR. Saya merasa git maupun berbagai PL yang hanya memproses per baris itu kurang elegan. Dalam 20 tahun karier saya, saya cuma pernah sekali melihat pendekatan yang lebih rapi seperti pada bahasa Ada. Sulit membuat sesuatu yang benar-benar elegan dan efisien, dan kalau sudah ada alternatif yang cukup bagus, semakin sulit lagi untuk membuat pendekatan baru menyebar luas.
  • Saya juga pernah terjebak dalam perdebatan ini saat masih muda. Alasannya karena saya salah mengira bahwa saya orang paling pintar di tim. Saya pikir pendapat saya yang paling penting. Saya percaya semua orang harus mendengarnya. Ternyata saya salah.
• Trade-off yang perlu dipertimbangkan di sini adalah, kalau memakai format selain teks, kegunaan alat umum seperti grep, diff, sed, dan version control akan menurun. Pada akhirnya ketergantungan pada alat khusus, format khusus, atau ekstensi IDE akan meningkat. Kekuatan filosofi Unix adalah komposabilitas lewat plain text. Ada satu pertanyaan yang bisa memotong perdebatan ini dengan mudah: kalau di editor kita bebas mengatur hanya lebar spasi indentasi pertama, apakah para pendukung tab masih punya argumen tambahan?
  • Pendekatan berbasis teks memang punya kelebihan, tetapi rasanya kita sempat bisa turun sedikit lalu mendaki gunung yang lebih tinggi, yaitu projectional editing, namun malah tersesat di dasar. Semua contoh itu bekerja lebih baik pada kode yang punya informasi struktural: misalnya, untuk pencarian simbol (yang jauh lebih sering saya pakai daripada grep teks) kita bisa memakai ast-grep, diff bisa mendukung perpindahan struktural atau mengabaikan perubahan yang tidak bermakna seperti semanticdiff.com, dan sebagai alternatif sed kita bisa memakai @codemod/cli. Untuk version control juga sudah banyak eksperimen, seperti di bahasa Unison, untuk menghindari conflict otomatis akibat perubahan non-semantik seperti urutan atau whitespace.
  • Ide ini terus muncul berulang kali, tetapi cost-benefit-nya kurang bagus karena alih-alih cukup menjalankan formatter sederhana sekali, kita malah membutuhkan alat yang sangat kompleks. Dalam praktiknya tidak terlalu penting setiap developer melihat tampilan sesuai seleranya masing-masing. Di semua tim tempat saya bekerja, kami menetapkan aturan bersama dan menegakkannya dengan formatter; meskipun awalnya tidak setuju, orang segera terbiasa. Perdebatan soal formatting adalah contoh klasik pemborosan waktu.
  • grep, diff, sed, dan merge berbasis baris sebenarnya alat yang buruk untuk memanipulasi kode. Saya rasa kita perlu memikirkan alat yang lebih baik daripada terus berdebat soal ini.
  • Kalau intermediate representation disimpan sebagai teks, maka grep/diff/sed tetap bisa bekerja. Jika hanya memakai formatter berbasis AST, kode bisa disimpan dalam bentuk yang sudah dinormalisasi sesuai AST tertentu, lalu editor akan mem-parsing AST itu, menampilkannya dalam format yang diinginkan pengguna, dan saat menyimpan mengubahnya kembali ke bentuk yang dinormalisasi.
  • Seluruh sistem operasi ini dibangun dengan ketergantungan pada file sumber seperti itu. Filosofi Unix juga benar-benar bersinar hanya ketika semua alat mempertimbangkan dan bisa mem-parsing plain text.
• Saya pikir formatting source code juga jelas punya unsur tipografi. Saya tidak setuju dengan anggapan bahwa ini murni soal selera pribadi. Formatting tertentu adalah alat untuk menyampaikan makna dan struktur secara efektif. Jika alat otomatis hanya menserialisasikan token minimum lalu memulihkannya lagi, nilai seperti ini akan hilang. https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
  • Para ahli percetakan sudah lama mencurahkan perhatian besar untuk jarak dan perataan pada tabel atau rumus. Orang luar sering tidak menyadarinya, tetapi ini sangat penting. Saya pikir source code juga bisa berkembang ke formatting yang lebih halus dan canggih.
  • Misalnya, ada keluhan bahwa formatter black untuk Python memecah query SQLAlchemy menjadi terlalu banyak baris sehingga keterbacaannya justru menurun.
  • Saya selalu heran kenapa banyak orang tidak bisa merasakan pentingnya tipografi pada kode.
  • Saya merasa sangat keliru kalau kita peduli pada tipografi kode tetapi di sisi lain mengikuti konvensi bahasa pemrograman secara tidak kritis; misalnya budaya yang dengan rela memakai kata seperti register, atau konvensi menuliskan pointer dengan tanda bintang (*). Setiap notasi sebenarnya bisa dibuat lebih intuitif dan lebih jelas, tetapi kita justru bertahan pada cara yang rumit dan sulit dibaca. Simbol maupun reserved word juga bisa diganti dengan istilah yang lebih akrab dan alami, tetapi kita terlalu terikat pada tradisi dan konvensi lama sampai mengorbankan keterbacaan. Sebagai contoh, dijelaskan bahwa fungsi strcpy di C pun bisa sepenuhnya disusun ulang dengan istilah dan sintaks yang lebih jelas dan mudah dibaca.
  • Dijelaskan bahwa deklarasi parameter di C terdiri dari modifiers, tipe data, dan nama, lalu menyoroti masalah keterbacaan deklarasi yang rumit dengan contoh seperti char argv[]. Ia juga menilai formatting gaya C++ (misalnya char a, b) bisa menimbulkan salah paham, sehingga gaya seperti itu sebaiknya dihindari.
• Saya tidak setuju dengan premis perdebatan ini. Formatting kode adalah sarana komunikasi yang sangat penting. Formatting yang baik menjadi sinyal bahwa developer (1) menyadari pentingnya formatting, (2) patuh pada aturan, (3) punya selera yang baik, dan (4) punya penilaian yang baik untuk menangani pengecualian. Empat hal ini adalah kemampuan penting yang memengaruhi kapasitas developer secara keseluruhan, lebih dari sekadar formatting. Namun auto formatter atau aturan linter melemahkan sinyal ini dan, seperti hukum Goodhart, membuat tujuan awalnya hilang.
  • Tulisan blognya pendek dan sederhana, jadi sangat disarankan membacanya langsung. Jangan langsung bereaksi hanya dari judulnya; akan lebih baik kalau konteks kata 'should' dan 'unnecessary' dipahami dulu.
  • Menurut saya, orang yang tidak peduli pada formatting kemungkinan (1) belum pernah mengedit satu file bersama banyak orang, (2) belum pernah melakukan branch merge, (3) belum punya pengalaman memelihara codebase besar, (4) belum punya pengalaman refactoring skala besar, (5) belum pernah menemukan riwayat kode atau memanfaatkan alat diff/perbandingan, (6) belum pernah mengembangkan alat otomatisasi untuk codebase, atau (7) gaya kerjanya hanya memikirkan diri sendiri tanpa kesadaran kolaborasi.
  • Kalau jawaban untuk semua butir itu adalah 'tidak', menurut saya cukup otomatisasi formatting saat pass/commit, lalu kalau otomatisasi itu tidak dijalankan biarkan CI mengembalikan error. Daripada terobsesi pada detail, lebih baik ikuti default saja, dan melepaskan gaya pribadi justru bisa jadi kelebihan. Kalau dibiarkan pada default, kode akan terasa akrab bagi siapa pun yang melihatnya. Lagi pula formatting dan linting memang berbeda, tetapi keduanya bisa diselesaikan sekaligus lewat alat otomatisasi.
  • Penilaian yang sama juga bisa dipelajari dari tulisan tangan; sambil bercanda ia menambahkan bahwa mulai sekarang PR seharusnya dikirim dalam tulisan sambung saja.
  • Mengandalkan "selera untuk memilih aturan formatting yang baik" justru cenderung memicu perdebatan dan membuang waktu. Lebih baik menyerahkannya pada formatter bawaan seperti di Go dan Rust.
• Upaya menyimpan kode berdasarkan syntax tree, lalu memperlakukan kode yang dilihat manusia sebagai hasil render dari sana, sudah ada sejak 20–25 tahun lalu. Ini adalah aliran yang berawal sejak refactoring pertama kali populer pada tahun 90-an. IDE seperti Visual Age pernah mengadopsi model yang menyimpan kode di database alih-alih file system. Intentional programming maupun model-based development juga bagian dari siklus ini. Inti refactoring adalah transformasi AST; mengganti nama simbol menjadi sangat mudah dan tidak perlu cari-ganti langsung di source code. Namun orang tetap terbiasa mengedit file, dan ada resistensi serta gesekan dalam memopulerkan pendekatan yang menyimpan struktur itu sendiri. Fakta bahwa kita masih terus berdebat soal formatting seiring waktu justru menunjukkan perlunya alternatif ini. Bahkan rename symbol yang robust di level bahasa atau editor pun sering kali belum tersedia dengan baik.
  • Ini dianggap mencampur lapisan abstraksi. AST pada akhirnya tetap harus disimpan ke file, jadi tidak terlalu berbeda dengan menjalankan alat yang AST-aware pada file yang bisa dibaca manusia. Format penyimpanan tidak terlalu penting; intinya adalah masalah alat yang lebih pintar. Contohnya diberikan pada Microsoft Roslyn maupun arah compiler modern yang ingin berinteraksi dengan codebase lewat API.
• Diberikan contoh langsung bahwa beberapa jenis formatting tidak bisa diturunkan hanya dari AST. Misalnya, ketika ada beberapa assignment, apakah tiga baris itu diratakan sejajar, disejajarkan berdasarkan '=', atau diberi tab indentasi untuk menonjolkan kedalaman struktur, semuanya berbeda. Jika ingin menekankan nilainya sendiri, angka bisa diratakan ke kanan; jika ingin menekankan struktur, variabel anggota bisa disejajarkan agar lebih mudah dilihat. Aspek kode yang ingin ditekankan penulis bisa berbeda-beda. Argumennya adalah bahwa tanpa metadata tambahan, informasi seperti ini tidak bisa diekstrak dari AST.
  • Saya paham maksudnya, tetapi dalam praktiknya saya hanya memakai dua cara pertama. Tujuan sebenarnya lebih ke keterbacaan daripada penekanan. Memang ada yang hilang saat dikonversi ke AST, tetapi untuk tingkat seperti ini saya rasa manfaat yang didapat jauh lebih besar. Lagi pula variasi penekanan semacam ini juga bisa tetap dicatat di AST. Misalnya, bisa dengan sesuatu seperti setValue([bar, glob], 1) atau sintaks komentar untuk style override, dan banyak pendekatan lain.
  • "Formatting kode yang diinginkan" pada akhirnya tetap subjektif; seperti pada contoh, ada orang yang suka 2/4/8 spasi, ada juga yang suka perataan kolom. AST tidak menyimpan informasi formatting source code, jadi itu tidak bisa diturunkan secara otomatis.
  • Contoh formatting kedua dan ketiga sebenarnya adalah masalah desain struktural (pelanggaran Law of Demeter), jadi bukan ranah formatting.
• Projectional Editing juga bisa diterapkan pada source text. Ada video contoh di JetBrains MPS yang merender tabel dari kode https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s. Ada harapan IDE bisa merender dictionary sebagai tabel. Saat ini pun sudah ada sebagian fitur yang mirip, seperti code folding, inlay hints, atau docstring yang dirender sebagai HTML https://x.com/efortis/status/1922427544470438381.
• Ini didefinisikan sebagai keterbatasan kita yang belum bisa menerima sesuatu yang lebih abstrak daripada plain text sekarang juga. Sekalipun mencoba, akhirnya tetap diturunkan menjadi proyeksi plain text. Akumulasi 'giant lookup table (GLUT)' dari Morse Code sampai Unicode dianggap telah membentuk budaya kita saat ini dalam mendekode simbol. Jika level abstraksi dinaikkan, set simbol yang lebih cocok untuk aplikasi sebenarnya bisa dibuat, tetapi alat yang sesuai tidak muncul. Akhirnya semuanya tetap diubah menjadi transmisi teks lalu di-parse lagi, seperti CSV atau Markdown. Untuk XML juga kadang ada editor khusus, tetapi pada akhirnya orang tetap ingin mengeditnya sebagai plain text. Meski begitu, ini juga tidak sepenuhnya positif karena ada masalah encoding karakter dan karakter khusus.
• Saya kadang bertanya-tanya kenapa artifact yang disimpan dan proyeksi kode yang benar-benar kita lihat harus sama. Akan bagus kalau bahkan git diff bisa dilihat sebagai proyeksi IR (intermediate representation). Berkat hadirnya alat AST seperti treesitter, kita jadi bisa membayangkan antarmuka yang membuat manusia lebih efisien menangani AST atau IR. Sebagai contoh, struktur ordered compilation di f# membantu menyederhanakan code review. Sebaliknya, dalam bahasa atau struktur yang membolehkan urutan bebas, untuk memeriksa satu diff kecil saja kita harus mondar-mandir ke banyak tempat untuk memahami konteks keseluruhan perubahan, yang merepotkan.
• Terkait eslint-config-airbnb, ada yang berbagi ketidaknyamanan. Isu representatifnya #1271, #1122. Ia menghabiskan lebih dari satu jam berkutat saat mencoba menerapkan airbnb config ke proyek yang sudah ada, dan merasa tidak produktif karena aturan-aturan yang tidak perlu padahal kodenya semula sudah sempurna. Akhirnya aturan itu dimatikan secara lokal, dan setelah itu tidak pernah lagi dipakai di proyek mana pun. Contoh ini menunjukkan betapa aturan lint yang salah bisa merusak produktivitas.