Ruff v0.16.0 — Aturan default diperluas besar-besaran dari 59 menjadi 413

• Ruff v0.16.0, linter dan formatter Python yang ditulis dengan Rust, menambah aturan yang aktif secara default dari 59 menjadi 413, sehingga dapat mendeteksi lebih luas kesalahan sintaks dan error runtime yang langsung terjadi tanpa konfigurasi terpisah
• Mendukung pemformatan blok kode Python yang ditandai di Markdown dengan python, py, pyi, pycon, dan lainnya, serta dapat diterapkan pada notebook Quarto
• ruff: ignore dan ruff: file-ignore ditambahkan, sehingga diagnosis pada baris kode logis atau seluruh file dapat ditekan; komentar dapat disisipkan otomatis dengan --add-ignore
• check dan format --check menampilkan perubahan perbaikan sebagai diff di bawah diagnosis secara default, dan pemeriksaan formatter juga mendukung JSON serta format output untuk anotasi CI GitHub/GitLab
• Sebagian besar dapat di-upgrade tanpa perubahan besar, tetapi perlu memeriksa dampak bertambahnya aturan default dan perubahan output JSON—beberapa nilai dapat menjadi null—terhadap konfigurasi serta alat otomasi yang sudah ada

---

Aturan default diperluas menjadi 413

• Ruff v0.16.0 adalah linter dan formatter Python berkecepatan tinggi yang ditulis dengan Rust, dan dapat dipasang melalui PyPI atau uv tool install ruff@latest
• Total aturan Ruff meningkat dari 708 pada v0.1.0 menjadi 968, tetapi aturan yang aktif secara default selama ini tetap 59
• v0.16 memperluas aturan default menjadi 413, sehingga masalah serius termasuk kesalahan sintaks dan error runtime yang langsung terjadi dapat dideteksi tanpa konfigurasi terpisah
  • Mencakup aturan kategori B dari flake8-bugbear, UP dari pyupgrade, serta RUF milik Ruff sendiri
  • Daftar lengkap dapat dilihat di dokumen Default Rules
• Proyek yang sudah menggunakan select atau extend-select juga dapat melihat aturan berguna yang sebelumnya belum diketahui melalui aturan default baru ini
• Untuk kembali ke aturan default sebelumnya, konfigurasikan seperti berikut

[lint]
select = ["E4", "E7", "E9", "F"]

• Perubahan ini terkait dengan proyek jangka panjang reklasifikasi aturan, dan pekerjaan terkait akan terus berlanjut

Pemformatan blok kode Markdown

• ruff format memformat blok kode fenced Python yang ada di file Markdown
• String info yang didukung adalah python, py, python3, py3, pyi, pycon
  • pyi diperlakukan sebagai format file stub
  • pycon diperlakukan sebagai format sesi REPL
  • Sisanya diformat seperti file Python biasa
• Nama bahasa yang diapit kurung kurawal seperti {python} juga dikenali, sehingga dapat digunakan untuk notebook Quarto
  • Jika memakai ekstensi .qmd, konfigurasi pemetaan extension mungkin diperlukan
• Di dalam blok kode, sebagian pemformatan dapat ditekan dengan fmt: off dan fmt: on
• Seluruh area dokumen Markdown dapat dikecualikan dengan komentar HTML <!-- fmt: off --> dan <!-- fmt: on -->
• Untuk mengecualikan semua file Markdown, tetapkan glob seperti *.md pada extend-exclude
• Detail perilakunya dapat dilihat di dokumen pemformatan kode Markdown

Komentar penekan diagnosis baru

• Setelah penekanan berbasis cakupan ruff: disable dan ruff: enable di v0.15, v0.16 menambahkan ruff: ignore dan ruff: file-ignore
• ruff: ignore, seperti noqa, dapat menekan diagnosis pada baris yang sama, atau ditulis sebagai komentar tersendiri untuk diterapkan ke seluruh baris logis berikutnya
  • Pada header fungsi yang ditulis beberapa baris, bagian dari def hingga titik dua diperlakukan sebagai satu baris logis
• ruff: file-ignore, seperti ruff: noqa, menekan diagnosis yang ditentukan di seluruh file
• Pada setiap komentar penekan, alasan penerapan dapat ditulis setelah kode aturan
• Opsi CLI --add-ignore otomatis menambahkan komentar ruff: ignore yang diperlukan
• Dalam mode pratinjau, nama aturan seperti unused-import juga dapat digunakan sebagai ganti kode seperti F401
• Spesifikasi komentar lengkap dirangkum dalam dokumen linter Ruff

Diff perbaikan dan format output

• check dan format sebelumnya juga mendukung --diff, tetapi bekerja terpisah dari diagnosis umum sehingga tidak ditampilkan bersama diagnosis yang menunjukkan alasan perbaikan
• Output default full di v0.16 menampilkan perbaikan linter dan formatter yang memungkinkan sebagai diff di bawah diagnosis
• format --check juga dapat menggunakan seluruh format output yang didukung linter
  • Dapat menghasilkan JSON yang dapat dibaca mesin
  • Dapat mengeluarkan format yang dirender GitHub dan GitLab sebagai anotasi di CI
• Format yang didukung dapat dilihat di bantuan CLI dan dokumen format output

Kompatibilitas dan stabilisasi

• Perubahan breaking di v0.16 hanya sedikit, sehingga sebagian besar dapat diperbarui tanpa banyak mengubah kode atau konfigurasi
• filename, location, end_location, fix.edits[].location, fix.edits[].end_location pada output JSON dapat menjadi null, alih-alih memakai string kosong atau baris 1 kolom 1 sebagai nilai default
  • Diagnosis yang terdampak saat ini sangat sedikit, tetapi pada aturan mendatang hal ini dapat menjadi lebih umum
• 12 aturan beralih dari pratinjau ke status stabil
  • Kompatibilitas signature fungsi Airflow 3 AIR303, pemberitahuan hak cipta CPY001, konversi float FURB164, min/max yang diurutkan FURB192
  • Penggabungan string literal koleksi ISC004, logging exception di luar exception handler LOG004, tipe pengembalian bool yang salah PLE0304
  • Argumen posisi berlebihan PLR0917, pengembalian StopIteration PLR1708, posisi None dalam Union RUF036
  • Akses annotation pada dictionary kelas RUF063, item duplikat di __all__ RUF068
• Beberapa perilaku stabil dari aturan yang sudah ada juga diterapkan secara default
  • BLE001 juga ditekan saat exception dicatat dengan metode logging selain critical, error, dan exception
  • FA102 memeriksa API tambahan yang kompatibel dengan PEP 585 seperti collections.abc
  • INT001·INT002·INT003 juga memeriksa pola penggunaan umum seperti menetapkan gettext ke builtins._
  • S310 menafsirkan binding literal string lokal untuk mengurangi false positive
  • S508·S509 mendukung API yang direkomendasikan pada PySNMP terbaru
  • UP019 mengenali bukan hanya typing.Text, tetapi juga typing_extensions.Text
• Perubahan lengkap dapat dilihat di rilis GitHub

[GN⁺]

Komentar Hacker News

• Saya menaikkan proyek Python sekitar 3 ribu baris dari v0.15.x ke versi baru; tidak memakan waktu lama, dan versi baru menemukan banyak masalah yang luput dari versi sebelumnya sehingga kualitas kode juga membaik
  Perbaikan manual sesuai saran: https://github.com/nickjj/plutus/commit/9af66d31f98bef841588...
  Mengaktifkan kembali aturan panjang baris: https://github.com/nickjj/plutus/commit/21789f89bbcee37913c1...
  Memaksa variabel yang tidak digunakan memakai prefiks _: https://github.com/nickjj/plutus/commit/a272c77b932e1c78558a...
  Perbaikan otomatis Ruff: https://github.com/nickjj/plutus/commit/6fe69cf88385ebdf9b8c...

• Senang melihat Ruff, ty, uv tetap aktif dikembangkan bahkan setelah Astral diakuisisi OpenAI

  • Saya sempat menantikan ty, tetapi akhirnya berhenti memakainya karena jauh tertinggal dari basedpyright. Yang fatal bukan kurangnya item pemeriksaan, melainkan false positive; selain itu juga tidak ada fitur baselining yang sangat berguna untuk codebase besar
    uv dan Ruff luar biasa, dan semoga ty suatu hari bisa mencapai level itu

• Mengejutkan melihat orang begitu antusias terhadap alat polisi sintaks yang menerapkan aturan sewenang-wenang masing-masing dan bahkan tidak bisa sepakat soal seperti apa kode Python yang baik
  Misalnya menggabungkan dictionary multi-baris menjadi satu baris sehingga merusak maksud komentar, lalu hanya membetulkan format remeh seperti dua spasi atau tanda kutip ganda. Masalah sebenarnya bukan spasi di akhir baris atau pengurutan import, melainkan list comprehension 10 baris yang sulit dipahami, dan alat-alat seperti ini tidak menangkapnya
  Di kantor, penggunaan pylint, flake8, black, dan Ruff menghasilkan ratusan commit untuk setiap perubahan; energi itu seharusnya bisa dipakai di tempat lain

  • Tujuan alat seperti ini adalah membuat kita fokus pada masalah nyata. Dengan mengotomatiskan keputusan lint, kita tidak perlu membuang tenaga berpikir untuk berdebat soal format di PR
    Jika menerima begitu saja hasil yang dijalankan otomatis, kita bisa keluar dari diskusi lint; tetapi di organisasi tanpa alat seperti ini, waktu nyata harus dihabiskan untuk memikirkan dan memperdebatkan format
  • Tampaknya penolakan bahwa linter membuang waktu sudah melewati batas yang wajar. Di lapangan, ada cukup bukti bahwa linter justru menghemat waktu, dan pada akhirnya intinya hanya bahwa linter kadang membuat perubahan yang tidak kita sukai
    Dalam pengembangan tim, alih-alih terlalu memaksakan preferensi pribadi, kita perlu mendengarkan pendapat sekitar dan meninjau ulang prioritas antara kolaborasi dan craftsmanship
  • Ruff mengenali komentar di akhir baris, mempertahankan tiap item di baris terpisah, dan hanya menambahkan koma trailing serta spasi. Jika ada koma trailing, Ruff juga tidak menggabungkan baris; hasil yang ditunjukkan tampaknya berasal dari Black
    Perilaku menggabungkan baris padahal ada komentar baris terlihat tidak tepat. Tanda kutip ganda di Python hanyalah pilihan gaya, dan jika ada tanda kutip ganda di dalam tanda kutip tunggal, Ruff juga membiarkannya apa adanya
  • Alat seperti ini justru menghemat energi tim. Tanpa alat, tiap developer punya standar berbeda soal format, kualitas kode, dan keterbacaan, sehingga diskusi tidak ada habisnya; lebih baik menyerahkannya ke Ruff
  • Itu digabung menjadi satu baris karena koma setelah item terakhir terlewat. Setidaknya di Black, jika koma trailing dipertahankan, item tidak akan dipadatkan, tetapi karena sering merusak format yang saya inginkan, saya tidak lagi menghubungkannya ke kode saya

• Akan bagus jika Go punya alat seperti Ruff. Banyak bahasa punya alat yang hebat, tetapi ekosistem Go terasa terfragmentasi, dan tidak ada alat yang terasa sematang Ruff, Oxc, Biome, Mago

  • Go punya Go Analysis Framework yang lebih baik: https://pkg.go.dev/golang.org/x/tools/go/analysis
    Karena relatif baru, ini belum begitu dikenal, tetapi menjadi dasar go fix dan go vet; tampaknya tim Go sedang berupaya agar penulis modul dapat dengan mudah mendefinisikan analysis pass kustom yang otomatis berjalan saat go fix dijalankan
    Dengan struct analysis.Analyzer, kita bisa mengakses AST, tipe, dan informasi SSA serta menggabungkan informasi antar-analyzer; jika dikompilasi menjadi binary dan diberikan ke go fix, toolchain akan menangani caching yang rumit. Karena dibuat langsung oleh tim Go dan disertakan dalam toolchain, alat seperti golangci-lint kemungkinan besar dalam jangka panjang juga akan terkonsolidasi ke framework ini
    Kita bisa meminta agen AI menulis analyzer Go Analysis dan menjalankannya lewat go fix; di proyek saya sendiri, ini juga saya pakai untuk menegakkan beberapa aturan secara otomatis dan deterministik, alih-alih mengandalkan instruksi Markdown yang tidak akurat
  • Sampai belum lama ini suasananya justru kebalikan: komunitas Python kesulitan karena kurangnya tooling dan semua orang menginginkan gofmt untuk Python. Ruff memang linter, bukan formatter, tetapi arah perkembangan ekosistem Python belakangan ini menggembirakan
  • Saya kurang paham maksud ekosistem Go terfragmentasi. Go punya alat formatting dan linting resmi, dan bahasanya sendiri sengaja dibatasi agar bahkan kode yang ditulis pemula pun memiliki bentuk yang konsisten
    Berbeda dengan Python atau TypeScript, yang alat resminya tidak memaksakan gaya tertentu, di Go sulit mendapatkan efek dramatis seperti saat pertama kali memakai Ruff atau Biome
  • Go adalah salah satu ekosistem tooling bahasa terbaik yang bisa digunakan tanpa IDE besar, dan golangci-lint juga cukup komprehensif. Distribusi Go sendiri sudah menyelesaikan banyak hal
  • golangci-lint sudah ada sejak lama dan digunakan secara luas

• Mengaktifkan 413 aturan secara default adalah perubahan yang baik karena sebagian besar proyek bisa mendapatkan lint yang berguna tanpa perlu mengutak-atik konfigurasi

  • Namun patut dipertanyakan apakah tiba-tiba dibanjiri 413 potensi peringatan pada proyek yang sudah ada benar-benar berguna; ini tampaknya lebih cocok untuk proyek baru
    Saat ini mungkin bisa menyerahkan semua peringatan lint kepada agen untuk diperbaiki sesuai standar yang ditentukan lalu membiarkannya beberapa jam, tetapi diagnosis mendetail yang disediakan Ruff sendiri tetap patut disambut

• Ruff juga membutuhkan fitur seperti stateVersion di Nix untuk menentukan kumpulan default yang akan diterapkan. Jika Ruff diperbarui di banyak repositori, setiap kali aturan default baru ditambahkan kita harus segera menonaktifkannya atau memperbaiki pelanggarannya, sehingga hasilnya sulit diprediksi
  Memang bisa saja menuliskan semua aturan yang ingin diaktifkan dalam allowlist, tetapi lebih baik menjaga konfigurasi tetap sederhana dan hanya menaikkan versi status ketika semua orang bisa meluangkan beberapa jam

  • Cara yang lebih tepat adalah mengunci versi Ruff yang diinginkan di pyproject.toml pada tiap proyek. Dengan begitu tiap proyek bisa menaikkan versi ketika sudah siap, tidak perlu mengoordinasikan banyak proyek sekaligus, dan jika satu tertinggal proyek lainnya tidak ikut terhambat
  • Menurut teks asli, kumpulan aturan default Ruff tidak berubah selama lebih dari 2 tahun, dan perubahan terakhir adalah v0.1.0
    https://github.com/astral-sh/ruff/releases/tag/v0.1.0

• Di era coding dengan agen, linting yang kuat lebih penting dari sebelumnya, dan saya ingin melihat alat seperti forbidigo di lebih banyak bahasa

  • Saya sedang meng-upgrade berbagai proyek, tetapi rasanya campur aduk. Saat menulis kode sendiri, saya menilai secara intuitif kapan harus melewati atau mengabaikan aturan, tetapi pada proyek yang mengaktifkan sebagian besar aturan pylint, kode justru menjadi lebih sulit dibaca karena trik-trik untuk memuaskan pylint
    Agen coding juga menghabiskan banyak token untuk memperbaiki masalah kecil, atau bahkan menonaktifkannya sama sekali saat tes gagal. Saya sudah mulai percaya pada akurasi umum hasil AI, tetapi penilaian terhadap kualitas kode masih sulit dipercaya

• Meski aturannya sudah sebanyak 413, setiap kali bergabung ke codebase baru kita tetap mengulang tiga perdebatan yang sama soal pengurutan import

• Senang rasanya karena sekarang penggunaan tanpa konfigurasi tampaknya direkomendasikan. Di .ruff.toml baru cukup menyisakan line-length = 300