Clean Code Notları

Murat ÖKSÜZER
[Link]
Robert C. Martin
Temiz kodun özellikleri

Verimli

Okunabilir

Test edilebilir

Sürdürülebilir

Yalın
Temiz kodun özellikleri

Tekrar (dublication) içermeyen

Anlamlı isimlendirmeli
Amaç:

Kodu bulduğumuzdan
temiz bırakmamızı
sağlayacak duyarlılığı
kazanmak
İsimlendirme
İsimlendirme niyeti belli etmelidir.

Yanlış bilgilendirmemelidir.

Telaffuzu mümkün olmalıdır.

Aranabilmelidir.

Kodlamadan kaçınılmalıdır.

Aynı konsepten bahsederken aynı isim kullanılmalıdır.

Aynı isim farklı konseptler için kullanılmamalıdır.

Zeki olmaya çalışılmamalı, sade herkesin anlayacağı isim kullanılmalıdır.

İsimlendirme

İsimleri değiştirmekten korkmamalı. Gerekli yerlerde

refactor yapılmalıdır.

Helper, Manager vb. genel isimler sınıfın herşeyi içeren

torbaya döndüğüne işaret ediyor olabilir.
Fonksiyonlar

Küçük olmalıdır. İdealde en fazla 20 satır olmalıdır.

Nested yapılar 2 seviyeden fazla olmamalıdır. If, else,

while gibi blokların içi metoda alınarak tek satıra
düşürülebilir.

Metod tek bir iş yapmalıdır. Tek sorumluluğu olmalıdır.

(Single Responsibility Principle)
Fonksiyonlar

Switch blokları doğası gereği n tane iş yaparlar.

Mümkün olduğunca kaçınmalıdır.

Polimorfizm kullanarak switch blokları refactor edilebilir.

(Abstract factory vb.)

Fonksiyonun ismi açıklayıcı olmalıdır. Yaptığı iş

anlaşılmalıdır.
Fonksiyonlar

Fonksiyonların argüman sayısı en aza indirgenmelidir.

Mümkünse sıfır, en kötü üç argüman almalıdır.

Argüman sayısı artıyorsa, argüman objesi oluşturmalı,

argümanlar bu sınıf ile geçirilmelidir.

Output argümanlar ekstra dikkat gerektireceğinden

mümkün olduğunca kaçınılmalıdır.
Fonksiyonlar

Boolean flag argüman alan fonksiyon büyük olasılıkla

birden fazla iş yapıyordur. Fonksiyon ayrılarak flag
argümanından kurtulunmalıdır.

Fonksiyonun yan etkisi olmamalıdır. Var ise, fonksiyon

isminde belirtilmelidir. (Unutmayın, fonksiyon bir iş
yapmalıydı)
Fonksiyonlar
Bir fonksiyon ya nesnenin durumunu değiştirmeli ya da
nesneyle alakalı bilgi dönmelidir. İkisini aynı anda
yapmamalıdır.

Örneğin;
public boolean set(String attribute, String value);
if (set("username", “unclebob"))...

Set metodu birden fazla iş yapıyor…

Fonksiyonlar

Fonksiyondan hata kodu dönmektense exception

fırlatmak tercih edilmelidir.

Try/Catch blokları fonksiyonlara dönüştürülmeli, blok

sadeleştirilmelidir.
Fonksiyonlar

Single-entry, single-exit kuralı uzun fonksiyonlar için

mantıklıydı. Metodlarımızı kısa tutacağımız için birden
fazla return, break kullanılabilir, hatta daha açıklayıcı bile
olabilir.
Yorumlar

Kötü koda açıklama yazmakla uğraşılmamalı, kodu

tekrar yazmalıdır.

Kod açıklamaya gerek kalmayacak kadar okunur ve

anlaşılır olmalıdır. Derdimizi kodla anlatmalıyız.
Yorumlar

Yorumun gerekli olduğu yerler de vardır.

Yasal zorunluluklar. Lisans bilgilerini içeren yorumlar.

Koddaki bir tasarımsal kararın arkasındaki neden yorum

olarak eklenebilir.
Yorumlar

Geliştiriciyi çalıştırılacak kodun sonuçlarına karşı

uyarmak gerektiğinde yorum kullanılabilir.

TODO yorumları unutulmamak şartıyla faydalıdır.

Javadoc yorumları dökümantasyon için faydalıdır.

Yorumlar

Kodu okuyarak anlayabileceğimiz şeyler için yorum

yazılmamalıdır. Gereksiz kalabalık yaparlar.

Yanlış bilgi içeren, yanlış yönlendiren yorumlar

tehlikelidir. Bir an önce kurtulunmalıdır.

Yoruma alınmış kod bırakılmamalıdır, silinmelidir. Siz

silmezseniz, birinin işine yarayacak düşüncesiyle kimse
silmeye cesaret edemez.
Formatlama

Kodun çalışır olması kadar okunabilir olması da

önemlidir.

Kod listesi okurken gazete okuyor hissi vermeli,

yukarıdan aşağıya genelden özele doğru bir yapı
oluşturulmalıdır.
Formatlama

Alakalı metodlar birbirine yakın yerleştirilmelidir.

Değişkenler kullanıldığı yere mümkün olan en yakın

yerde tanımlanmalıdır.

Yatay satır uzunluğu, sayfada sağa doğru scrola gerek

bırakmamalıdır.
Formatlama

Takımca formatlamanın nasıl olacağına karar vermeli ve

tüm geliştiriciler bu kurallara uymalıdır.
Hataları Yönetme

Hata kodu dönmektense Exception kullanılmalıdır.

Böylece çağıran kod hata kodu kontrol etmekten
kurtulur ve esas işi yapan kod, hata handling kodundan
ayrıldığı için daha temiz olur.
Hataları Yönetme
Unchecked exception tercih edilmelidir. Checked
exception fırlatan bir metodun catch’i 3 seviye
yukardaysa, exceptiondaki bir değişiklik tüm seviyelerin
değişmesine ve yeniden compile-deploy edilmesine
sebep olmaktadır.

Checked exception olmadan da sağlam yazılım

yapılabilir. Örneğin; C#, C++, Python ve Ruby dillerinde
Checked exception yoktur.
Hataları Yönetme

Exception içine hata ile alakalı içeriksel bilgiler de

konulmalıdır. Ne yapmaya çalışırken hata oluştuğu
bilgisi debug yaparken yardımcı olacaktır.
Hataları Yönetme

Duruma özel nesne ile çözülebilecek exceptional

case’ler, try/catch ile değil, bu nesne ile çözülmelidir.
(SPECIAL CASE PATTERN [FOWLER]
 Hataları Yönetme
try {
MealExpenses expenses = [Link]([Link]());
m_total += [Link]();
} catch(MealExpensesNotFound e) {
m_total += getMealPerDiem();
}
// yerine
MealExpenses expenses = [Link]([Link]());
m_total += [Link]();
// Special Case obejesi
public class PerDiemMealExpenses implements MealExpenses {
public int getTotal() {
// return the per diem default }
}
Hataları Yönetme

Metodlardan null dönmek hatalara davetiye çıkarır. Null

dönmemeli, Exception fırlatmalı veya SPECIAL CASE
nesnesi kullanılmalıdır.

Metodlara null parametre geçirmek, null dönmekten

daha kötüdür. Null parametre geçirmekten sakınmalıdır.
Birim Testleri
TDD (Test Driven Development) pratiğinin üç temel yasası vardır.

1- Fail eden bir test yazmadan production kodu yazma

2- Fail etmeye yetecek kadardan fazla test yazmaya devam

etme.

3- Fail eden testi geçecek kadardan fazla production kod

yazma. Testi geçecek kadar geliştirmen yeterli.
Birim Testleri

Bu sayede fail edecek test yaz - kodu geliştir - fail

edecek test yaz şeklinde bir döngüye girilir.

Böylece production kodu testlerle beraber üretilir.

Birim Testleri
Test sınıfları da production kod kalitesinde temiz
tutulmalıdır. İkinci sınıf vatandaş muamelesi görmemelidir.

Testler temiz tutulmadığında sürdürülemez ve bir süre

sonra production kod testsiz kalma tehlikesiyle karşı
karşıya kalır.

Testsiz kalan production kodda değişiklik yapmaya

cesaret etmek zordur. Nerenin bozulduğu anlaşılamaz
Birim Testleri
Test metodlarındaki assert sayısı en aza indirgenmelidir.
Testler çalıştırıldığında fail eden bir assert yüzünde onun
altında kalan assertlerin sonuçları muamma olmaktadır.

One assert per method en idealidir.

Test metodu sadece bir konuyu test etmelidir. Birden

fazla durum için farklı test metodları yazılmalıdır.
F.I.R.S.T. kuralı

Testler F.I.R.S.T. kuralına uymalıdır:

Fast: Testler hızlı çalışmalıdır. Yavaş çalışan testi kimse

çalıştırmak istemez, hatalar tespit edilemez.

Independent: Testler birbirinden bağımsız çalışabilmelidir.

F.I.R.S.T. kuralı

Repeatable: Testler her ortamda tekrarlanabilmelidir.

Self-validating: Test sonucunu anlamak için fazla düşünmeye gerek

olmalıdır. Test ya geçmeli ya fail etmelidir. Durumu anlamak için
çıktıları incelemek vs. gerekmemelidir.

Timely: Testler zamanında yazılmalıdır. Production kodla beraber

geliştirilmelidir.
Sınıflar

Yukarıdan aşağıya statik değişkenler (önce publicler

sonra private statikler), sonra instance değişkenleri
(public, private sırasında) daha sonra public metodlar ve
private metodlar gelmelidir.

Sınıfı okurken gazete okuyor hissi vermelidir.

Sınıflar

Sınıflar olabildiğince küçük olmalıdır. Sorumluluklar

olabildiğince küçük parçalara bölünmelidir.

Sınıfa isim vermekte zorlanıyorsanız, sınıfın olması

gerektiğinden büyük olduğu anlaşılabilir.

Single Responsibility Principle der ki, bir sınıfın değişmesi

için sadece bir neden olmalıdır.
Sınıflar

Sınıfın sorumluluğu arttıkça, değişime uğrama olasılığı o

kadar artmaktadır.

Sınıfın manipüle ettiği değişken sayısına bakarak bu

değişkenlerden yeni sınıflar üretilebilir mi diye
sorgulamalıdır.