Google Rilis Rust Style Guide: 5 Aturan yang Layak Ditiru

Google mempublikasikan Rust Style Guide yang mengatur lebih dari sekadar format kode: panduan ini juga menetapkan aturan desain API dan implementasi. Kode Rust di Google dipakai di google3, Android, ChromeOS, Fuchsia, dan Chrome. Dua aturan yang paling sering mengejutkan pengembang di luar Google: hindari Rc dan Arc, dan jangan pakai async serta await di Chromium. Aturan desain API bersifat mengikat untuk kode library, tapi hanya rekomendasi kuat untuk kode aplikasi. Halaman resminya dibaca untuk artikel ini pada 22 Oktober 2026.

TL;DR

• Google merilis Rust Style Guide yang mencakup desain API, bukan hanya format.
• Aturan desain API mengikat untuk library, tapi hanya rekomendasi untuk aplikasi.
• Dua aturan yang paling menonjol: hindari Rc/Arc, dan jangan pakai async/await di Chromium.
• Formatting diserahkan ke rustfmt, jadi panduan ini fokus ke hal yang tidak bisa diotomasi.

Kenapa Google membuat style guide sendiri?

Karena tujuannya berbeda dari style guide Rust pada umumnya. Selain konsistensi dan keterbacaan, panduan ini punya satu tujuan tambahan: mempermudah Large-Scale Changes, yaitu refactoring besar lintas codebase yang dibantu tooling.

Lima tujuan yang disebutkan eksplisit: aturan harus mengutamakan keterbacaan dan kemudahan pemeliharaan di atas kecepatan menulis, aturan harus mendukung otomasi, aturan harus konsisten dengan ekosistem Rust yang lebih luas bila memungkinkan, setiap aturan harus punya manfaat nyata, dan aturan yang hanya berfungsi mencegah debat gaya kecil harus dijaga seminimal mungkin.

Poin keempat itu yang paling menarik. Alasannya sederhana dan jujur: setiap pengembang dan reviewer di Google harus mengingat aturan-aturan ini, jadi aturan yang tidak memberi manfaat konkret hanya menambah beban kognitif. Ini alasan yang jarang muncul di dokumen gaya, dan sebaiknya ditiru oleh tim yang sedang menyusun panduan internal sendiri.

Untuk hal yang bisa diotomasi, Google tidak menulis aturan manual. Formatting diserahkan ke rustfmt, dan panduan ini secara eksplisit menyuruh mengikuti aturan gaya Rust publik sejauh tidak bertentangan dengan panduan mereka. Dua rujukan yang disebut adalah Rust Style Guide resmi dan Rust API Guidelines.

Aturan mana yang paling berdampak di kode sehari-hari?

Untuk sebagian besar tim, yang paling terasa ada empat: jangan pakai glob import, hindari Rc dan Arc, pilih enum daripada bool untuk parameter API, dan gunakan expect alih-alih unwrap.

Larangan glob import punya alasan yang jelas: impor semacam itu menyembunyikan asal sebuah nama, sehingga pembaca harus menebak dari crate mana sebuah tipe berasal. Panduan ini juga menetapkan bahwa satu pernyataan use sebaiknya mengimpor item dari satu modul saja, dan tipe sebaiknya diimpor lalu dipakai tanpa kualifikasi, sementara pemanggilan fungsi tingkat atas justru dikualifikasi dengan nama modul. Pola terakhir ini membuat pembaca langsung tahu sebuah fungsi milik modul mana tanpa harus melacak daftar impor di atas file.

Soal Rc dan Arc, panduan ini menyarankannya dihindari. Alasannya bukan karena keduanya buruk secara teknis, tapi karena kepemilikan bersama menyembunyikan siapa yang sebenarnya memiliki data. Pada codebase besar yang harus bisa direfactor otomatis, kepemilikan yang eksplisit jauh lebih mudah dianalisis tooling. Aturan pendampingnya, prefer borrows over deep copies, berada di arah yang sama: salinan dalam menyembunyikan biaya, sementara borrow membuat biaya itu terlihat di tanda tangan fungsi.

Untuk parameter, enum lebih dipilih daripada bool. bool memang ringkas, tapi di titik pemanggilan nilai true dan false tidak menjelaskan apa pun. Enum memaksa nama yang menyebut maksudnya. Aturan ini terlihat kecil, tapi efeknya besar pada keterbacaan kode yang memanggil fungsi dengan banyak argumen.

Aturan	Untuk kode library	Untuk kode aplikasi
Aturan desain API	Mengikat	Rekomendasi kuat
Aturan organisasi kode	Mengikat	Mengikat
Larangan glob import	Mengikat	Mengikat
Hindari Rc dan Arc	Mengikat	Mengikat
Prefer expect over unwrap	Mengikat	Mengikat

Bagaimana panduan ini membedakan library dan aplikasi?

Untuk kode library, aturan desain API bersifat mengikat. Untuk kode aplikasi, aturan yang sama hanya rekomendasi kuat, dan panduan ini menyuruh aplikasi mengutamakan kesederhanaan serta langsung pada tujuan dibanding kegunaan ulang yang luas.

Pembedaan ini masuk akal karena keduanya punya tekanan yang berbeda. Library dipakai proyek lain, sehingga perubahan kecil di tanda tangan fungsi bisa memaksa banyak pihak ikut berubah. Aplikasi menyelesaikan masalah spesifik, jadi generalisasi dini justru merugikan. Kalimat yang dipakai panduan ini tegas: hindari generalisasi dan abstraksi prematur, fokus pada kebutuhan yang ada sekarang.

Praktisnya, kalau sedang menulis kode aplikasi dan sebuah aturan desain API terasa memaksa penambahan lapisan abstraksi yang belum dibutuhkan, panduan ini sendiri membolehkan untuk tidak mengikutinya. Yang tidak boleh dilanggar adalah aturan organisasi kode dan aturan gaya penulisan.

Kenapa async dan await dilarang di Chromium?

Karena di Chromium, panduan ini secara eksplisit menandai larangan penggunaan async dan await dengan label chrome. Larangan itu berlaku untuk codebase tersebut, bukan untuk semua kode Rust di Google.

Label dalam tanda kurung siku di panduan ini menandai aturan yang hanya berlaku untuk codebase tertentu. Pada halaman panduan, label chrome muncul 10 kali, jadi porsi aturan yang spesifik per codebase memang kecil dibanding total isinya. Beberapa aturan lain juga berlabel chrome, misalnya prefer small crates dan use flat file layout untuk sumber rust_library. Artinya, kalau tim bukan Chromium, aturan berlabel itu tidak otomatis berlaku, meski alasannya tetap layak dipelajari.

Ini bagian yang paling sering disalahpahami ketika panduan ini dibaca di luar Google. Dari 14 bagian utama di panduan ini, hanya sebagian aturan yang diberi label chrome, jadi membaca daftar isi lalu menyimpulkan bahwa Google melarang async di seluruh kode Rust adalah kesimpulan yang salah. Yang benar: ada codebase yang melarangnya, dan alasannya spesifik pada codebase itu, bukan pada bahasa Rust secara umum.

Bagaimana menerapkan panduan ini di tim sendiri?

Mulai dari yang bisa diotomasi lebih dulu, lalu tambahkan aturan manual satu per satu. Panduan Google sendiri menempatkan rustfmt sebagai lapisan pertama, dan aturan manual hanya untuk hal yang tidak bisa ditangani tooling.

Urutan yang masuk akal: pasang rustfmt dengan konfigurasi tetap, tambahkan clippy pada level yang disepakati, lalu pilih tiga sampai lima aturan manual yang paling sering menimbulkan debat di review. Larangan glob import dan preferensi enum di atas bool adalah kandidat bagus karena keduanya mudah diperiksa dan efeknya langsung terasa di keterbacaan. Aturan yang hanya menambah beban tanpa manfaat konkret sebaiknya tidak dimasukkan, sesuai prinsip yang dipakai panduan ini sendiri.

Dokumen lengkapnya, termasuk daftar aturan per bagian seperti organisasi kode, kepemilikan dan borrowing, tanda tangan fungsi, penanganan error, trait, dan concurrency, bisa dibaca di Rust Style Guide Google. Bagian implementation concerns di sana juga memuat aturan yang jarang dibahas di tempat lain, misalnya jangan menjalankan kode sebelum main, jangan memakai rantai kombinator iterator ketika iterasi langsung lebih jelas, dan gunakan context string untuk memperjelas pesan assertion.

Aturan apa yang jarang dibahas di panduan lain?

Bagian implementation concerns memuat beberapa aturan yang tidak biasa ditemui, misalnya jangan menjalankan kode sebelum main, jangan memakai rantai kombinator iterator ketika iterasi langsung lebih jelas, dan jangan memanggil panic catch unwind.

Larangan menjalankan kode sebelum main menyentuh pola yang sering muncul tanpa disadari, misalnya inisialisasi global yang bergantung pada urutan. Pada codebase besar, urutan inisialisasi yang implisit sulit dilacak dan sulit diuji. Aturan tentang rantai kombinator iterator berada di arah berbeda: kombinator memang ringkas, tapi kalau tujuannya lebih jelas ditulis sebagai loop, versi loop lebih mudah dibaca dan di-debug.

Larangan panic catch unwind punya alasan yang lebih dalam. Menangkap panic dan melanjutkan eksekusi berarti mengasumsikan state program masih konsisten setelah sesuatu yang seharusnya tidak terjadi sudah terjadi. Di sebagian besar kasus, asumsi itu tidak benar, dan kegagalan yang muncul belakangan justru lebih sulit dilacak daripada panic aslinya.

Bagaimana hubungannya dengan clippy dan rustfmt?

Keduanya adalah lapisan otomasi, sementara panduan ini mengisi bagian yang tidak bisa diperiksa tool. rustfmt menangani format, clippy menangkap pola berisiko, dan sisanya butuh keputusan manusia.

Panduan Google menyebut bahwa sebagian besar konvensi format ditegakkan otomatis oleh rustfmt, dan sisanya diatur lewat aturan tertulis. Pembagian ini masuk akal untuk ditiru: setiap aturan yang bisa diperiksa mesin sebaiknya diserahkan ke mesin, karena aturan manual yang seharusnya bisa diotomasi hanya menambah beban review tanpa menambah kepastian. Aturan manual sebaiknya disimpan untuk hal yang butuh pertimbangan konteks, misalnya apakah sebuah abstraksi sudah pantas diekstrak menjadi trait atau belum.

Apakah panduan ini bertentangan dengan konvensi komunitas Rust?

Sebagian, dan panduan ini mengakuinya secara terbuka. Alasannya adalah tujuan tambahan berupa dukungan untuk Large-Scale Changes, yang tidak selalu jadi prioritas di proyek lain.

Pada proyek kecil, sebagian aturan di sini bisa terasa berlebihan, misalnya pembagian crate yang halus atau pelarangan glob import yang ketat. Yang tetap berguna di semua ukuran proyek adalah prinsipnya: pilih pola yang membuat asal sebuah nama jelas, buat kepemilikan data eksplisit, dan serahkan hal yang bisa diotomasi ke tooling.

Berapa banyak aturan yang ada di panduan ini?

Panduan ini disusun dalam bagian besar seperti organisasi kode, format dan estetika, kepemilikan dan borrowing, tanda tangan fungsi, pelaporan error, tipe, trait, concurrency, dan implementation concerns. Jumlah aturan per bagian bervariasi, dan sebagian aturan diberi label chrome sehingga hanya berlaku untuk codebase tertentu. Membacanya dari daftar isi saja tidak cukup, karena banyak aturan baru masuk akal setelah membaca alasannya.

FAQ

Apakah panduan ini wajib diikuti di luar Google?

Tidak wajib. Ini panduan internal Google yang dipublikasikan terbuka, dan sebagian aturannya spesifik pada codebase mereka. Yang bisa diadopsi adalah prinsipnya, bukan seluruh aturannya.

Apakah Google melarang async dan await di semua kode Rust?

Tidak. Larangan itu berlabel chrome, artinya berlaku untuk Chromium. Codebase lain di Google punya aturannya sendiri, dan larangan tersebut tidak otomatis berlaku untuk proyek Rust di luar Google.

Apa pengganti unwrap menurut panduan ini?

expect. Alasannya, expect memaksa penulis menyertakan pesan yang menjelaskan asumsi di balik pemanggilan, sehingga kegagalan di runtime memberi konteks yang bisa langsung dipakai untuk menelusuri penyebabnya.

Apakah formatting diatur dalam panduan ini?

Tidak secara detail. Formatting diserahkan ke rustfmt, dan panduan ini menyuruh mengikuti aturan gaya Rust publik sejauh tidak bertentangan. Fokus panduan ada pada desain API dan keputusan yang tidak bisa diotomasi.