if'leri yukarı, for'ları aşağı itmek

Fonksiyon içinde koşullu ifadeleri yukarı taşımak

• Bir fonksiyon içinde if koşulu varsa, bunu çağırana (caller) taşımayı düşünün.
• Fonksiyonun önkoşulları içeride kontrol edip koşul sağlanmadığında 'hiçbir şey yapmaması' yerine, çağıranın önkoşulu kontrol etmesini sağlayarak önkoşulun sağlandığını tipler aracılığıyla garanti edin.
• Önkoşulları özellikle 'yukarı taşımak', genel olarak kontrol işini azaltabilir; bu da bu kuralın motivasyonlarından biridir.

Döngüleri aşağı taşımak

• Veri odaklı düşünceden çıkan bu kural, nesnenin 'batch' kavramını tanıtır; batch işlemlerini temel durum kabul eder ve skaler sürümü batch sürümünün özel bir durumu olarak ele alır.
• Başlıca faydası performans artışıdır; başlangıç maliyetini dağıtabilir ve işleme sırası konusunda esneklik sağlayabilir.
• Örneğin, FFT tabanlı polinom çarpımında, polinomları birden çok noktada aynı anda değerlendirmek tek tek değerlendirmekten daha hızlı olabilir.

GN⁺ görüşü

• Bu yazıdaki en önemli nokta, yazılım geliştirmede performansı ve kodun açıklığını artırmaya yönelik iki programlama kuralı olan 'koşulları yukarı taşımak' ve 'döngüleri aşağı taşımak'tır.
• Bu kurallar, kodun okunabilirliğini artırmaya, performansı optimize etmeye ve hata olasılığını azaltmaya yardımcı olur.
• Yazılım mühendisliğinin karmaşıklığını yönetmek ve verimli kod yazmak için içgörü sunduğundan, bu yazı birçok geliştirici için ilgi çekici ve faydalıdır.

[GN⁺]

Hacker News görüşleri

• Veri odaklı tasarıma dair tavsiyeye gösterilen tepkinin şaşırtıcı olduğu söyleniyor. Forum kullanıcılarının çoğu web uygulamaları yazdığı için bu tavsiye onlara anlamsız görünebilir. Günlük işinizde komut önbelleği hakkında düşünmeniz gerekmiyorsa bu tavsiyeyi görmezden gelmeniz gerektiği belirtiliyor. Mike Acton'ın "Typical C++ Bullshit" konuşmasına bakılırsa bu tavsiyenin neden önemli olduğu anlaşılabilir.
• Programcıların kodu "küçük ölçekte" güzel hale getirmeye önem verdiği, ancak tüm kod tabanının doğru tasarımına yeterince önem vermediği söyleniyor. Bir fonksiyon iyi adlandırılmışsa, iyi bir arayüze sahipse, net bir amacı varsa, uygun şekilde belgelenmişse ve yan etkileri aşırı kullanmıyorsa, fonksiyonun dağınık olması ya da if ve for yerleşimi çok da dert edilmemeli deniyor.
• Bilim alanında programlamaya başlamış birine göre, küçük optimizasyonlar önemlidir. for döngülerinin sırasını yanlış kurmak, bir simülasyonun çalışma süresini 1 haftadan 1 saate indirebilir. Bu geçmişe sahip biri, for ve if sıralamasını içgüdüsel olarak optimize eder.
• Bir "container" varsa, container için fonksiyon yazmak yerine, container'ın tuttuğu alan düzeyindeki "Thing" için fonksiyon yazılması gerektiği söyleniyor. Bunun kodu daha esnek hale getirdiği ve çekirdek alanla uygulamanın ilgi alanlarını daha net ayırdığı belirtiliyor.
• if koşullarını yukarı taşımanın, fonksiyonun önkoşullarını ve sonkoşullarını doğrudan fonksiyon tanımında görünmez hale getirmesi gibi bir dezavantajı olduğu söyleniyor. Büyük projelerde bu tür fonksiyonlar amaçlanan bağlamın dışında yeniden kullanılabilir ve hatalara yol açabilir. Sözleşme çerçeveleri kullanmak bir çözüm olabilir, ancak bu durumda koşulları hem sözleşmede hem de kodda iki kez yazmak gerekir.
• Rust kullanılan örnekte, Rust'ın güçlü tür sisteminin diğer dillerde gerekli olan savunmacı programlamayı gereksiz kıldığı belirtiliyor. Bir C programcısının, fonksiyona verilen işaretçinin geçerliliğini kontrol etmeden NULL referansı üretmesi istenen bir durum değildir. Bazı if koşulları fonksiyonun altında değil üstünde olmalı ve hatalar düzgün şekilde yayılmalıdır.
• Yazının belirli kod örneklerine bağlanacakmış gibi göründüğü ama aslında öyle olmadığı söyleniyor. Beklenen kod örnekleri yerine başka bir örnek sunuluyor.
• Uygun bağlam olmadan bu tavsiyenin garip, hatta kötü bir tavsiye olabileceği söyleniyor. for döngüleri ve if ifadeleri de sonuçta kontrol akışı işlemleridir; bu yüzden yazıdaki bazı iddialar anlamsız görünüyor. Performansla ilgili iddia en güçlü olanı olsa da, genel bir tavsiye için bu ancak en son dikkate alınması gereken nokta deniyor.
• Genel kuralların gerçek koda uygulanabilir olduğundan emin olunmadığı belirtiliyor. Bu tür kurallar çoğu zaman yanlış bir dogma olarak görülüyor ve genç programcılar bunları yanlış anlayıp daha kötü kod yazabiliyor. Koşulların çoğu zaman walrus'a bağlı olması nedeniyle if koşullarını yukarı taşımak mümkün olmuyor.
• Önkoşul if kontrollerini çağırana taşımak korkunç bir fikir olarak değerlendiriliyor. Özel durumlarda iyi bir fikir olabilir, ancak genel durumda istenmiyor. Kütüphanelerde önkoşulların dış sınırda kontrol edilmesi, iç uygulamanın iç varsayımlar olmadan ilerleyebilmesi için gerekli görülüyor. Kontrolü çağırana bırakmak bu amacın kendisini boşa çıkarıyor.