Fonksiyon uzunluğu tartışması yazılım geliştirmede klasik bir konu. Sabit bir sayı vermek mümkün ama asıl mesele sayı değil, anlam. **Yaygın referans noktaları** Robert C. Martin (Clean Code), fonksiyonların tek bir ekrana sığması gerektiğini savunur, yaklaşık 20-30 satır. Linus Torvalds Linux çekirdeği için benzer bir eşik önerir. Ancak bu rakamlar kural değil, yönlendirmedir. **Sayıdan çok sorumluluk sayısı** "Fonksiyon uzunluğu" tartışmasının asıl odak noktası aslında şu soru: bu fonksiyon kaç şey yapıyor? Tek Sorumluluk İlkesi (Single Responsibility Principle) gereği bir fonksiyon bir şey yapmalı. Eğer fonksiyon 15 satırda 5 iş yapıyorsa kısadır ama kötüdür. 60 satırda yalnızca bir iş yapıyorsa, yorumlarla iyi belgelendirilmişse kabul edilebilir olabilir. **Okunabilirlik testi** Pratik kural: fonksiyonun yaptığı işi tek cümleyle açıklayabiliyor musunuz? Cevap "ve" içeriyorsa, örneğin "veriyi doğrular ve veritabanına kaydeder ve e-posta gönderir", fonksiyon büyük olasılıkla bölünmeli. **Bağlam önemlidir** Veri dönüşüm işlemleri, matematiksel hesaplamalar ya da durum makineleri doğası gereği daha uzun fonksiyonlara yol açabilir. Böyle durumlarda fonksiyon uzunluğu kötü tasarımın değil, problemin karmaşıklığının yansımasıdır. **Somut öneri:** - 20 satır altı: sorunsuz - 20-50 satır: dikkatli olun, bölünebilir mi değerlendirin - 50 satır üzeri: neredeyse her zaman bölünmeli - 100 satır üzeri: ciddi tasarım sorunu işareti **Refactor etmeden önce test yazın** Uzun bir fonksiyonu parçalara bölerken önce mevcut davranışı kapsayan testler yazmak hataları önler. Fonksiyon uzunluğu azalırken davranış değişmemeli.