ifs naik dan fors turun

Menaikkan kondisional di dalam fungsi

• Jika ada kondisional if di dalam fungsi, pertimbangkan untuk memindahkannya ke pemanggil (caller).
• Alih-alih fungsi memeriksa prasyarat di dalamnya dan "tidak melakukan apa pun" jika kondisi tidak terpenuhi, biarkan pemanggil memeriksa prasyarat sehingga melalui tipe dapat dijamin bahwa prasyarat telah terpenuhi.
• Terutama ketika prasyarat "dinaikkan", jumlah pemeriksaan secara keseluruhan dapat berkurang, dan ini adalah salah satu motivasi aturan ini.

Menurunkan perulangan

• Aturan yang berasal dari pemikiran berorientasi data ini memperkenalkan konsep 'batch' pada objek, menjadikan operasi batch sebagai kasus dasar, dan memperlakukan versi skalar sebagai kasus khusus dari versi batch.
• Peningkatan performa adalah manfaat utamanya, karena biaya awal dapat didistribusikan dan urutan pemrosesan bisa menjadi lebih fleksibel.
• Sebagai contoh, pada perkalian polinomial berbasis FFT, mengevaluasi polinomial secara bersamaan di banyak titik bisa lebih cepat daripada evaluasi satu per satu.

Opini GN⁺

• Hal terpenting dalam tulisan ini adalah dua aturan pemrograman, yaitu 'menaikkan kondisional' dan 'menurunkan perulangan', untuk meningkatkan performa dan kejelasan kode dalam pengembangan perangkat lunak.
• Aturan-aturan ini membantu meningkatkan keterbacaan kode, mengoptimalkan performa, dan mengurangi kemungkinan terjadinya bug.
• Tulisan ini menarik dan bermanfaat bagi banyak pengembang karena memberikan wawasan tentang cara mengelola kompleksitas rekayasa perangkat lunak dan menulis kode yang efisien.

[GN⁺]

Komentar Hacker News

• Ada pendapat bahwa reaksi terhadap saran mengenai desain berorientasi data cukup mengejutkan. Karena sebagian besar pengguna forum menulis aplikasi web, saran ini bisa tampak tidak relevan. Jika dalam pekerjaan sehari-hari Anda tidak perlu memikirkan instruction cache, maka saran ini sebaiknya diabaikan. Lihat "Typical C++ Bullshit" dari Mike Acton untuk memahami pentingnya saran ini.
• Ada pendapat bahwa para programmer peduli membuat kode terlihat rapi pada "unit kecil", tetapi tidak cukup peduli pada desain keseluruhan codebase yang tepat. Jika sebuah fungsi diberi nama dengan baik, memiliki antarmuka yang baik, tujuan yang jelas, terdokumentasi dengan semestinya, dan tidak terlalu banyak menggunakan efek samping, maka tidak perlu terlalu memikirkan apakah fungsi itu tampak berantakan atau bagaimana penempatan if dan for.
• Dari seseorang yang mulai belajar pemrograman di bidang sains, ada pendapat bahwa optimasi kecil itu penting. Menggunakan urutan for loop yang salah bisa mempersingkat waktu eksekusi simulasi dari 1 minggu menjadi 1 jam. Orang dengan latar belakang seperti ini akan secara naluriah mengoptimalkan urutan for dan if.
• Ada pendapat bahwa ketika ada "container", kita seharusnya menulis fungsi untuk "Thing" pada level domain yang dikandungnya, alih-alih menulis fungsi untuk container tersebut. Ini membuat kode lebih fleksibel dan memisahkan perhatian domain inti dan aplikasi dengan lebih jelas.
• Ada kekurangan dari memindahkan "if" ke atas, yaitu membuat prasyarat dan pascakondisi fungsi tidak lagi bisa dilihat langsung pada definisi fungsi. Dalam proyek besar, fungsi seperti itu bisa digunakan kembali di luar konteks yang dimaksud dan menyebabkan bug. Menggunakan framework contract bisa menjadi salah satu solusi, tetapi kondisi harus ditulis dua kali, di contract dan di kode.
• Dalam contoh yang menggunakan bahasa Rust, sistem tipe Rust yang kuat mencegah defensive programming yang diperlukan di bahasa lain. Tidak diinginkan jika programmer C tidak memeriksa validitas pointer yang diberikan ke fungsi lalu memicu referensi NULL. Beberapa if memang seharusnya berada di bagian atas fungsi, bukan di bawah, dan error harus dapat dipropagasikan dengan baik.
• Ada pendapat bahwa artikel tersebut tampak seperti akan mengarah ke contoh kode tertentu, tetapi ternyata tidak. Sebagai ganti contoh kode yang diharapkan, contoh lain diajukan.
• Tanpa konteks yang memadai, saran ini bisa terdengar aneh bahkan buruk. for loop dan if statement sama-sama operasi kontrol alur, jadi beberapa klaim dalam artikel tampak tidak bermakna. Klaim tentang performa adalah yang paling kuat, tetapi untuk saran umum hal itu seharusnya menjadi pertimbangan terakhir.
• Ada pendapat bahwa sulit yakin apakah aturan umum seperti ini benar-benar bisa diterapkan pada kode nyata. Aturan semacam ini sering dilihat sebagai dogma yang keliru, dan programmer muda bisa salah memahaminya lalu menulis kode yang lebih buruk. if tidak bisa dipindahkan ke atas ketika kondisinya sering bergantung pada walrus.
• Ada pendapat bahwa memindahkan if prasyarat ke pemanggil adalah ide yang mengerikan. Dalam kasus khusus itu mungkin ide yang bagus, tetapi secara umum hal itu tidak diinginkan. Dalam library, prasyarat seharusnya diperiksa di batas eksternal agar implementasi internal bisa berjalan tanpa asumsi internal. Mengandalkan pemeriksaan oleh pemanggil justru meniadakan tujuannya.