--- title: "Erken Dönüş (Early Return) ile İç İçe If Cehennemine Son Vermek" url: "https://cilginyazilim.com/blog/erken-donus-ile-ic-ice-if-cehennemi" description: "Erken dönüş (early return) deseni iç içe if bloklarını nasıl düzleştirir? PHP ve JavaScript örnekleriyle adım adım refactoring, kapsam kuralları ve sınırları." published: "2026-10-18T10:00:00+03:00" modified: "2026-10-18T10:00:04+03:00" author: "Çılgın Yazılım" category: "Yazılım Geliştirme" tags: ["yazılım geliştirme", "php", "javascript", "kod incelemesi", "refactoring", "kod kalitesi", "yazılım tasarımı", "erken dönüş deseni", "early return", "temiz kod", "okunabilirlik", "guard clause", "karmaşıklık"] site: "Çılgın Yazılım" language: "tr" --- # Erken Dönüş (Early Return) ile İç İçe If Cehennemine Son Vermek Beş kat iç içe geçmiş if bloğu okunmaz değil, sadece yanlış sıralanmıştır. Erken dönüş desenini adım adım uygulayalım. **Erken dönüş deseni**, bir fonksiyonun geçersiz durumları en başta eleyip geri dönmesi, asıl işi ise girintisiz biçimde en dışta yapmasıdır. İngilizce kaynaklarda *early return* ya da *guard clause* adıyla geçer. Yaptığı iş kulağa basit gelir, ama beş kat iç içe geçmiş bir `if` bloğunu tek bakışta anlaşılır hâle getiren şey çoğu zaman tam olarak budur. ![Erken dönüş öncesi ve sonrası kod yapısı](https://cilginyazilim.com/uploads/blog/2026/08/erken-donus-ile-ic-ice-if-cehennemi-ozet.png) *Girinti derinliği, okunabilirliğin en ucuz ölçüsüdür.* ## Problem: mutlu yol en dipte İç içe koşullarla yazılmış kodun ortak özelliği şudur: fonksiyonun asıl yaptığı iş, en derin girinti seviyesindedir. Okuyan kişi o satıra ulaşana kadar beş ayrı koşulu zihninde tutmak zorunda kalır. ```php function siparisiOnayla(?array $siparis, ?array $kullanici): string { if ($siparis !== null) { if ($kullanici !== null) { if ($siparis['durum'] === 'bekliyor') { if ($siparis['tutar'] > 0) { if ($kullanici['bakiye'] >= $siparis['tutar']) { // Asıl iş burada — beşinci seviyede return 'onaylandi'; } else { return 'yetersiz_bakiye'; } } else { return 'gecersiz_tutar'; } } else { return 'gecersiz_durum'; } } else { return 'kullanici_yok'; } } return 'siparis_yok'; } ``` Bu kodun hatası mantıkta değil, *sıralamada*. Her `else` dalı bir hata durumu; her `if` dalı ise bir sonraki hata kontrolüne kapı açıyor. Yani gerçekte düz bir doğrulama listesi var, ama piramit gibi yazılmış. ## Çözüm: önce ele, sonra çalış Erken dönüş uygularken kural tek cümledir: **fonksiyonun devam edemeyeceği her durumu en başta yakala ve hemen dön.** ```php function siparisiOnayla(?array $siparis, ?array $kullanici): string { if ($siparis === null) { return 'siparis_yok'; } if ($kullanici === null) { return 'kullanici_yok'; } if ($siparis['durum'] !== 'bekliyor') { return 'gecersiz_durum'; } if ($siparis['tutar'] <= 0) { return 'gecersiz_tutar'; } if ($kullanici['bakiye'] < $siparis['tutar']) { return 'yetersiz_bakiye'; } // Mutlu yol: girintisiz, en görünür yerde return 'onaylandi'; } ``` Satır sayısı yarıya indi, girinti derinliği beşten bire düştü ve en önemlisi: fonksiyonun ne yaptığı son satırda, aramaya gerek kalmadan görünüyor. Bu, [kod incelemesinde geri bildirimin](https://cilginyazilim.com/blog/kod-incelemesinde-neyi-nasil-elestirmeli) hızlanmasını da sağlar — inceleyen kişi zihinsel yığın tutmak zorunda kalmaz. ## Aynı desen JavaScript tarafında Asenkron kodda erken dönüş daha da değerlidir, çünkü `await` zincirleri girintiyle birlikte hızla okunmaz hâle gelir. ```javascript async function kullaniciProfiliGetir(id) { if (!id) return { hata: 'id_gerekli' }; const yanit = await fetch(`/api/v1/users/${id}`); if (!yanit.ok) return { hata: 'istek_basarisiz', kod: yanit.status }; const veri = await yanit.json(); if (!veri.aktif) return { hata: 'pasif_hesap' }; return { profil: veri }; } ``` > Pratik ölçüt: bir fonksiyonda üçüncü girinti seviyesini gördüğünüzde durup sorun — "bu koşullardan hangisi aslında bir doğrulama?" Cevap genellikle "hepsi"dir. ## Desenin sınırları Erken dönüş her yere uygun değildir. Üç durumda dikkatli olmak gerekir. ### Kaynak temizliği gerektiren kod Dosya tanıtıcısı, veritabanı bağlantısı veya kilit açtıysanız, ortadan dönmek temizliği atlatabilir. Bu durumda `try/finally` ya da dilin sunduğu kapsam-sonu mekanizmasını kullanın; erken dönüş yine mümkündür ama temizlik `finally` içinde olmalıdır. ### Transaction içinde Veritabanı işlemi açtıysanız ve ortadan dönerseniz, işlem askıda kalabilir. CodeIgniter'da `$db->transException(true)` veya açık `rollback` çağrısı bu riski kapatır. Bu konuya [transaction izolasyon seviyeleri](https://cilginyazilim.com/blog/transaction-izolasyon-seviyeleri-pratikte) yazısında ayrıntılı değinmiştik. ### Anlamlı tek çıkış gerektiren ekip kuralları Bazı ekiplerde "tek giriş, tek çıkış" kuralı yerleşiktir. Bu kural eski C alışkanlıklarından gelir ve modern dillerde faydası tartışmalıdır; yine de ekip kuralıysa tartışmayı kod incelemesinde değil, [teknik tasarım notu](https://cilginyazilim.com/blog/teknik-tasarim-notu-nasil-yazilir) düzeyinde açmak daha verimlidir. Aynı sadeleştirme mantığı veri yapılarında da geçerlidir; [değişmez nesneler](https://cilginyazilim.com/blog/degismezlik-immutability-pratik-rehber) koşul sayısını baştan azaltır. ## Ölçülebilir kazanç Erken dönüşün faydası öznel bir "daha güzel duruyor" hissi değildir; ölçülebilir. Döngüsel karmaşıklık (cyclomatic complexity) aynı kalır — koşul sayısı değişmemiştir — ama **bilişsel karmaşıklık** (cognitive complexity) belirgin biçimde düşer, çünkü bu metrik iç içe geçmeyi ayrıca cezalandırır. PHPStan, SonarQube veya ESLint'in `complexity` kuralı bu farkı doğrudan raporlar. ```bash # Bilişsel karmaşıklığı raporlayan hızlı bir kontrol composer require --dev phpstan/phpstan vendor/bin/phpstan analyse app --level=6 ``` Ölçüm alışkanlığı önemlidir: refactoring öncesi ve sonrası aynı komutu çalıştırıp sayıyı kaydedin. Aksi hâlde "daha temiz oldu" iddiası kod incelemesinde tartışma konusu olmaya devam eder. Metodun kaynağı ve tanımı için [SonarSource'un bilişsel karmaşıklık raporu](https://www.sonarsource.com/docs/CognitiveComplexity.pdf) iyi bir başvuru noktasıdır. ## Sonuç Erken dönüş deseni, kod yazmanın değil kod *sıralamanın* tekniğidir: geçersiz durumları başa alır, asıl işi en görünür yere taşır. Uygularken üç adımı izleyin — her `else` dalını bir doğrulama olarak yeniden yazın, doğrulamaları fonksiyonun başına toplayın, mutlu yolu girintisiz bırakın. Kaynak temizliği ve transaction sınırlarına dikkat ettiğiniz sürece bu değişiklik davranışı değiştirmez, yalnızca okunabilirliği artırır. Bir sonraki kod incelemesinde üç kat girintiden derin bir fonksiyon gördüğünüzde bu deseni önerin; çoğu zaman beş dakikalık bir değişiklik, aylarca sürecek bir okuma yükünü ortadan kaldırır. ## Sıkça Sorulan Sorular ### Erken dönüş "tek çıkış noktası" ilkesine aykırı değil mi? Tek çıkış ilkesi, elle bellek yönetimi yapılan C gibi dillerde kaynak sızıntısını önlemek için doğmuştu. Çöp toplayıcısı veya kapsam-sonu temizliği olan modern dillerde bu gerekçe büyük ölçüde ortadan kalkar. Kaynak açan fonksiyonlarda ise erken dönüşü try/finally ile birlikte kullanmak hem güvenli hem okunur olur. ### Kaç koşuldan sonra erken dönüşe geçmeliyim? Sayıdan çok girinti derinliği iyi bir ölçüttür. Üçüncü seviyeye inen her fonksiyon adaydır. Tek bir if/else ikilisini erken dönüşe çevirmek genelde kazanç sağlamaz, hatta gereksiz gürültü yaratabilir. ### Erken dönüş performansı etkiler mi? Pratikte hayır. Koşul sayısı değişmediği için yürütülen karşılaştırma adedi aynı kalır; bazı durumlarda geçersiz girdi daha erken elendiği için birkaç işlem tasarrufu bile olur. Kazanç performansta değil, bakım maliyetindedir. ### Bu deseni mevcut kod tabanına nasıl yayarım? Toplu bir refactoring yerine "dokunduğunuz yerde uygulayın" kuralı işe yarar. Bir hata düzeltirken veya özellik eklerken o fonksiyonu erken dönüşe çevirin. Böylece değişiklikler küçük kalır, kod incelemesi kolaylaşır ve regresyon riski dağıtılmış olur. --- Kaynak: [Erken Dönüş (Early Return) ile İç İçe If Cehennemine Son Vermek](https://cilginyazilim.com/blog/erken-donus-ile-ic-ice-if-cehennemi)