Clean Code Hakkında

Clean Code nedir?
Clean code yazılan kodun herhangi bir ekstra açıklamaya gerek duymaksızın anlaşılabilecek düzeyde okunabilirliği olan koddur. Bu anlaşılabilirliği sağlamak için ise gerekli bazı başlıklar vardır ve bunlardan 4 tanesi şu şekildedir:

1. İsimlendirme
Yazdığımız kodlarda birçok isimlendirme yaparız. Bunlar bazen bir harf bazen bir kelime bazen ise bir sözcük grubu olabilir ama yapılan isimlendirme ne kadar uzun ya da ne kadar kısa olursa olsun eğer verilen isimlendirme o kodu doğru yansıtmıyorsa veya yeterince açık değilse ne yazık ki yaptığımız isimlendirme kötü bir isimlendirmedir.

Örn: Öğrencilerin vize notlarını, final notlarını ve ödev notlarını girdi olarak alıp dönem sonu notuna dönüştürecek bir projemiz olduğunu varsayalım. Kullanacağımız isimlendirmeler eğer “int not1,not2,not3;” şeklinde ise bu isimlendirme sayısal değerlerimizin notları temsil ettiğini bize göstermekte lakin hangisi olduğunu tek başına anlatabilecek açıklıkta değildir. O zaman “int VizeNot,OdevNot,FinalNot;” şeklinde yapacağımız bir isimlendirme bütün program boyunca bizim hem okunurluğumuzu arttıracak hem de neyi ifade ettiğimizi çok net bir şekilde belirli edecektir.

Projemiz üzerinde tek çalışan kişi biz olmayabiliriz bu da demektir ki kodunuz üzerine tartışmalar, öneriler ve konuşmalar olabilir. Bu yüzden yaptığımız isimlendirmeler Telaffuz Edilebilir İsimler olmalıdırlar.
Örn: Yeterli anlamına gelen “adequate” sözcüğü yerine “enough” sözcüğünü tellafuz etmek ve dolayısıyla da kullanmak çok daha doğru olacaktır.

Bazen ise kısa isimlendirmeler bize daha kolay gelir belki bir sayı belki tek bir harf ama bu sefer de karşımıza şu çıkar İsimler Aranabilir Olmalıdır. Bir hafta isimlendirmesi yapacağımızı varsayarsak ufak bir “d” harfini ya da “7” rakamını kullanmak ne kadar kolay ve masum gözükse de bir çok kodun ya da isimlendirmenin içerisinde dahi bulunabilecek bu isimleri bir kod havuzunda aramanın samanlıkta iğne aramaktan bir farkı olmayacaktır. Bunun yerine “HAFTANIN_GUNLERI ya da haftaninGunleri” gibi tanımlamalar çok daha kolay bulunabilecek isimlerdir.

Gerekli olan bir arayüz (interface) ve onu gerçekleştirecek somut bir sınıf (implementation) yazıldığı zaman aynı isme ama farklı özelliklere sahip iki kodumuz oluyor elimizde.
Bu isim bizim için “ShapeFactory” olsun. Arayüz isimlendirmesi yapmamız gerekirken Interfaces kelimesinin baş harfi olan “I” harfi sıkça kelimenin “ShapeFactory” isminin başına gelerek “IShapeFactory” şeklinde bir isimlendirme pratiğine gidilmektedir ancak bu pratik bilgi verme konusunda oldukça zayıfken dikkat dağıtmakta ise “I” harfi ile başlayan tonlarca kelimenin bulunduğu o kod havuzunda tam bir öncüdür. O yüzden isimlendirme değişikliğinin arayüz yerine sınıf üzerinde yapılması -ki bu da ismin sonuna “implementations” kelimesinin ilk 4 harfinin ismin sonuna getirmesiyle gerçekleştirilir- okunabilirliği çok daha yüksek yapacak ve isimlendirmeden kaynaklanan dikkat dağılmanızı minimuma indirgemekte size çok yardımcı olacaktır. “IShapeFactory” yerine “ShapeFactoryImpl” isimlendirmesini de tercih ettik ama sınıf ve arayüzlerle olan alakamız daha sonlanmadı.
Kullandığımız sınıf isimleri isim ya da isim tamlamalarından oluşmalı, asla fiil isimleri kullanılmamalıdır. Çünkü burada kullanmadığımız o fiilleri metotlara devredeceğiz.
Metot isimleri “sayfayiSil(),kaydet()” gibi fiil ya da zarf tamlamalarından oluşmalıdır.
Farklı parametlere sahip kurucular kullanmaktansa “static” yapıcı metotları da kullanmaya başladıktan sonra -sırasıyla “Complex.FromRealNumber(23.0)” yerine “new Complex(23.0)” örnekleri verilebilir- “Interface” ve “Implementation” kullanımımız da artık Clean Code şeklinde.

Amacımız okunabilirliği yüksek bir bilmece yazmak değil, o yüzden Kelime Oyunu Yapmaktan Kaçının. Elinizde birden fazla amaç varsa bırakın birden fazla da kelime olsun ya da tek bir amacınız varsa da bütün kelime havuzunuz yerine tek bir isimlendirme her zaman okunabilirliği daha yüksek tutacaktır.

Örneğin “Controller,Manager ya da Driver” kelimelerini farklı sınıflar için beraber kullanmamız kafa karışıklığı oluşturacaktır. Aralarından en uygununu seçip onunla yola devam edebilirsiniz.

Bazen ise ilk tanımlamaları yaparken verdiğimiz isimler bize amacını tam anlamıyla belirtiyormuş gibi gözükebilir ama aslında gerçekten de bunu yapabiliyor mu? Bunun için o kelimeyi tek başına gözlemlememiz gerekecektir. Örneğin bir ev adresi için değişkenleri yazarken “street, houseNumber,state” şeklinde yazdığımızda state kelimesinin -State kelimesi eyalet,şart,resmi,beyan etmek gibi birçok farklı anlama sahiptir. — burada eyalet anlamına geldiği çok açık. Peki ya sadece state olarak görürsek? Şimdi işler değişiyor çünkü siz State kelimesini bir koşulu belirtmek için de kullanmış olabilirsiniz. Bunun gibi durumlarda bir öneke ya da “Address” isminde bir sınıfa ihtiyacımız olduğu aşikar. Öneki tercih edip “State” kelimesini “addrState” olarak güncelledik.
Bütün isimlendirmelere önek koymak da kodun okunurluğunu düşürecektir .

Örneğin bir “GasStationDeluxe” isimli bir uygulamamız olsun. Bu uygulamada yapacağım bütün isimlendirmelere GSD önekini koymamız ya da bir hesap modülüne “MailingAdress” Sınıfını ekleyip ismini “GSDAccountAdress” yaptığımızı varsayalım. Müşteriler de “MailingAdress“ sınıfına ihtiyaç duyduğu zaman bu kadar uzun ve sadece “Adress” yazmak yeterince açık ve netken ekstradan oradaki 10 harflik öneke ihtiyacımız olmayacaktır çünkü o önek kodun okunabilirliğini ciddi oranda düşürecektir.

2. Koşul Kullanımı

Elbette kodun hiç koşulu ya da kontrol akışı olmasaydı kodun okunabilirliği yüksek oranda artardı ama bu onları kullanmayacağımız anlamına gelmiyor.
Zaten zıplamalar ve dallanmalar kodumuzu karmaşıklaştırırken bir de bizim kendi işimizi zorlaştırmamız taktir edersiniz ki pek de akıl karı olmayacaktır. Elimizdeki koşul ve döngüleri doğal, günlük dilde kullandığımız ve okuyan kişinin tekrar okuma ihtiyacı duymayacağı şekilde yazmamız kodumuzun okunabilirliğini arttıracaktır.
Örn: Bir bireyin maaşı her ayın 10’unda yatmaktadır ve bunu yazarken “if(maasGunu==10) do {Ode}” şeklinde yapılan bir kod
“if(maasGunu !=10) do(Odeme)” şeklinde olan bir koddan daha anlaşılabilir olacaktır.
Ya da boyu 175 cm nin üzerindekilerin uzun kabul edildiğini varsayarsak boyun 175 cm den uzun ise uzunsun derken kodda if(175 <= boy) yazmamız kodumuza doğallığını kaybettirecektir.

Elbette tek önemli olan içindeki değil aynı zamanda blok sırası da.
If/else bloklarında elimizden geldiğince ilk blokta üç farklı noktaya değinmeyi tercih ederiz. Negatif ve pozitif durum arasında kaldıysak ilk bloğu pozitif, basit ve kompleks durum arasında kaldıysak basit, ilginç ya da şüpheli bir durum ve basit ya da şüphesiz durumlar arasında kaldığımızda ise ilginç ya da şüpheli olan durumu seçmek de kodumuzun okunabilirliğini arttıracaktır.
Peki her zaman kodu kısaltmak okunabilirliği arttırır mı?
bu soru Ternary (üçlü) operatörü -(<koşul>? a:b), if (<koşul>) {a} else {b} gösteriminin kısa olan şeklidir — için sorabileceğimiz cevabı tartışmalı olan bir sorudur.
Saati on ikilik birimde “am” veya “pm” kavramları ile kullandığımızı varsayalım. Bu durumda Ternary ile yazabileceğimiz kod:
time_str += (hour >=12) ? “pm” : ”am”;
şeklinde olurken if/else ile yazacağımız bloklar şu şekilde olacaktır:
if (hour >=12) {
time=str += “pm”;
} else {
time_str += “am”;
}
Bu konu tartışmalı olduğu için projenizde okunabilirliği hangi versiyonda daha fazla olacak ise ona karar verip kullanmanız çok daha iyi olacaktır.
Son olarak ise kısa devrelere değinelim. Birçok dilde, boolean operatörleri kısa devre yaparlar ve biz de kaşla göz arasında bu durumu kendimiz için bir avantaja dönüştürürüz.
Örn:
Elimizde doğru olma olasılığı çok yüksek olan a değişkeni ve yanlış olma ihtimali çok yüksek olan bdeğişkeni olsun. if(a||b) şeklinde yazacağımız boolean operatöründe tek bir doğru sonucun doğru olarak çıkmasına neden olacağı için a değişkenini önce koymak bize zaman ve anlaşılırlık kazandırabilecektir. Ya da bencer şekilde if (b && a) şeklinde yazabileceğimiz bir boolean operatöründe ise tek bir yanlış sonucun yanlış çıkmasına neden olacağı için b değişkenini önce koymak bize zaman ve anlaşılırlık kazandırabilecektir.

3. Döngü Kullanımı
Döngülerde ise durum yine anlaşılabilirlik üzerine olacaktır. Sürekli ışıkların parladığı bir film izlediğimizi varsayalım. Bu filmin en sonuna epilepsi uyarısı koymak tamamen anlamsız olacaktır ya da bir eylem gerçekleştirirken neden yatığımızı yapmadan önce değil de yaptıktan sonra düşünmek tamamen manasız olacaktır. Aynı mantıkta biz de önce yapıp sonra sorgulama işlemini gerçekleştiren do/while döngüsünden kaçınmayı tercih etmeliyiz. Ki bu kaçınma bize bir kayıp yaratmayacaktır çünkü bütün do/while döngüleri aynı zamanda While döngüleri ile de yazılabilmektedir.
Kısaca önce düşünüyoruz sonra eyleme döküyoruz.

4. Yorum Kullanımı
Elinizdeki kodu yorum satırı yazmadan açıklayamıyorsanız yorum satırı yazmak yerine kodu tekrar yazın. Çünkü unutmayın ki “EN İYİ YORUM SATIRI OLMAYAN YORUM SATIRIDIR.”

Peki neden?
Çünkü görünen köy kılavuz istemez.
Çok basit, sizin kodlarınız ulaşılması gereken bir köy ve yorum satırı ise kılavuzlarınız. Eğer köyünüz yeterince görünebilir -ki bu durumda okunabilir- ise bir kılavuza ihtiyacınız olmayacaktır.
Ayrıca SDLC kavramlarının ana çıkış noktalarından biri olan ve kaçınılmaz olan projelerin bakımı ise yorum satırlarının güncellenmemesine ve dolayısıyla da her okuduğunuzda sizi köye değil de bataklığa götüren bir kılavuz olacaktır.

Eğer kodunuz kötü ise kötüdür yazıp süsleyebileceğiniz hiçbir kod satırı o kodu daha iyi yapmayacaktır bu yüzden cesur olun ve kodunuzu tekrar yazmaktan çekinmeyin.
Örneğin:
//Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) && (employee.age >65))

Gibi bir kod kullanmaktansa alttaki kodu tercih ederiz

İf(employee.isElligibleForFullBenefits())

Bazı yorumlar ise zorunludur ve faydalıdır örneğin:
Yasal yorumlar
Telif hakları ve yayım hakları yasal sebeplerden dolayı sizi kod satırı yazmak zorunda bırakacaktır ama bunu da yaparken bütün şart ve koşulları koymak yerine standart bir lisans ya da dış doküman referansı çok daha iyi olacaktır.

Bilgilendirici Yorumlar
Bir satırın test halinde olduğunu ya da çalıştırılması halinde uzun zaman alacağı gibi uyarıları içeren ve kullanımı faydalı olan kısa yorumlardır.

TODO (YAPILACAKLAR) Yorumları
Anlık olarak gerçekleştirilemeyen değişiklikler, eklemeler ya da yarım kalan kısmın tamamlanması gibi durumları belirtmek için kullanılan oldukça faydalı yorumlardır.

Bu bahsedilenlerin dışında kalan çoğu yorum kötü yorumdur ve sadece verim kaybına sebep olur. Bu yorumlara ise; bilgilerin yersiz verilmesini, yanlış verilmesini, silinmesi gereken kodların yorum satırına alınmasını, her kapama parantezinden sonra yazılan ufak yorumları, günlük gibi yazıp kaynak kod sistemlerinin halihazırda yaptığı işi yaparak zaman kaybettiren yorumları ve bir fonksiyon ya da değişken kullanabilecekken kolaya kaçıp yazılan yorumları örnek gösterilebiliriz.

Şunu da unutmayalım Clean Code yazmanız aşağıdaki yavru pandayı da mutlu edecektir.