Selam,
Bu yazıda Robert Cecil Martin’in yazdığı Clean Code kitabının ‘Functions’ bölümünden öğrendiklerimi sizinle paylaşacağım.
- Fonksiyonların ilk kuralı: “Fonksiyonlar kısa olmalıdır”. Fonksiyonların ikinci kuralı: “daha da kısa olmalıdırlar”. Uzunluk olarak bir sayı belirtmek ne kadar doğru olur bilemiyorum ama 20 satırdan uzun olmamasına dikkat edelim.
- If-Else / For / While gibi kod blokları 1 satır uzunluğunda olmalıdır, bu satır da bir fonksiyon çağırmalıdır. ‘Naming’ kısmında öğrendiklerimizi unutmadan, bu fonksiyon vereceğimiz isim de fonksiyonun amacı hakkında okuyucuya bilgi vermelidir.
- Fonksiyon 1 şey yapmalıdır. Bu 1 şeyi yapmak birden fazla adım gerektirebilir. Yazdığımız X fonksiyonun 1 şey yapıp yapmadığını kolayca test edebiliriz: Eğer bu fonksiyondan kendisine pek benzemeyen, farklı bir isimde olan Y fonksiyonu çıkarabiliyorsak, X fonksiyonu aslında 1 değil 2 şey yapıyormuş.
- Fonksiyondaki kodların aynı soyutlama seviyesinde olması gereklidir. Soyutlamadan kast edilen şey High Level — Low Level olması. Mesela:
Bu Low Level’dır. High Level örneği ise:
- “Switch — Case” yapısını fonksiyonlara yerleştirmek yerine yazdığımız Class’ların içine yerleştirmeye gayret edebiliriz. Örneğin elimizde şöyle bir kod olduğunu varsayalım:
Elimizde Student Class’ı var, 2 tür Student olsun. Bunlardan biri “UnderGrad”, diğeri ise “Grad”. Yukarıdaki fonksiyon ise belirtilen öğrenci türüne ait okul ödemesini hesaplıyor.
Bu fonksiyonun birkaç sıkıntı vardır. Mesela farklı öğrenci türleri eklendikçe, yukarıdaki Switch-Case yapısı git gide uzayacak. Diğer bir sıkıntı ise her iki öğrenci türünde farklı işlemlere sebep olacak her türlü fonksiyonda yukarıdaki gibi Switch — Case yapısı yer almak zorunda.
Bunun önüne geçmek için Student Class’ına ait nesne yaratırken “Factory Design Pattern” ve Inheritance’dan yararlanabiliriz. Base Class olarak Student; Child Class olarak UnderGradStudent ve GradStudent olacak.
Yazacağımız Factory’de uygun türde nesne yaratmak için Switch — Case kullanacağız. “calculateFee()” fonksiyonu ise Child Class’lar tarafından override edilecek.
- Fonksiyonların ideal argüman sayısı 0'dır. 0 değilse 1, 1 değilse 2, 2 değilse 3'tür. Ama 3'den fazlasından kaçmak lazım. Bunun sebebi de argüman sayısı arttıkça yazacağımız test case sayısı da artıyor. Argüman sayısı azaltmak için benzer durumda olan argümanları kapsayacak bir Class yazabiliriz:
Circle makeCircle(double x, double y, double radius);Bunun yerine:
Circle makeCircle(Point center, double radius);- Fonksiyonların “side-effect” adı verilen yan etkileri olmamalıdır. Yukarıdaki maddelerden birinden fonksiyonun 1 şey yapması gerektiğini söylemiştik, o halde yapacağı 1 şey dışında başka bir şey yapmamalıdır. Örnek olarak Clean Code kitabında yer alan şu örneğe bakabiliriz:
Fonksiyonun ismine baktığımız zaman, yapacağı 1 şeyin şifre kontrolü olduğunu görüyoruz. Ama burada işleri bozan bir satırlık kod var:
Session.initialize();Şifre kontrolü dışında, oturum başlatma işlemini de gerçekleştiriyor. Ama hani bu fonksiyon 1 şey yapacaktı!?!?
- Elimizde bir kaç fonksiyon olduğunu, ve bu fonksiyonların başarısız oldukları zaman hata kodu döndürdüklerini düşünelim. Bu fonksiyonları kendi yazdığımız fonksiyondan çağırırsak, If — Else yapısı ile her fonksiyonun hata kodu döndürüp döndürmediğini kontrol etmemiz gerekir. Bu da kodu karışık hale getirmekten başka bir işe yaramaz. Kitaptaki örnek:
Hata kodu döndürmek yerine, başarısız olduğunu Exception atsa, biz de bunu yakalasak kod daha kolay okunur bir halde olmaz mı:
Bu bölüm için diyeceklerim bu kadar. Bir sonraki bölümde ise ‘Comment’ bölümünden öğrendiklerimi sizinle paylaşacağım.
Görüşmek üzere :)
Güncelleme
“Comment” bölümüyle ilgili olan yazıya şu linkten ulaşabilirsiniz:
Kaynak:
- Martin, R. C., & Han, L. (2012). Clean code. Beijing: Publishing House of Electronics Industry.
