İngilizce’de “clean coding” (temiz kodlama) denilen mevzu ile ilgi, cüz-i irademden dökülen bir takım fikir ve ilmi bilgileri,  siz değerli okurlarla paylaşacağım.

Temiz Fonksiyonlar

Malumunuz fonksiyonlar (methodlar) bir programın eli kolu değildir ama programın hayata dokunması sürecidir. Fonksiyonlar doğru kullanılmazsa, çok yanlış anlaşılabilir, büyük felaketleri doğurabilir.  Buradaki ibret doğal olarak fonksiyonlar için de aynen geçerlidir.

Bir program bir problemi çözmek üzere bir takım işler yapacağından, programda işi yapan, haliyle fonksiyonlardır. Bu sebepten ötürüdür ki fonksiyon isimlerinin ve tanımlamalarının iyi yapılması, programın işini hakkı ile yapmasında yadsınamaz bir paya sahiptir. Bir fonksiyon okunduğunda, okuyan kişinin beyninde bağlantı kuracağı bir şeyleri uzun süreler aramamalı, hemen gideceği yere gitmelidir. Bu da fonksiyonu yazanın pekala da yardımcı olabileceği bir konudur. Çiçek gibi kod yazmanın bazı basit, temel kuralları vardır. Bu kuralların bazıları biliniyor bazılarını ben uydurdum. Aklınıza yatmayanı zaten boş veriniz. Söz konusu kurallar şöyle:

• Fonksiyonun adı, fonskiyonun sorumluluğunu ve söz konusu mevzuyu çok^5 temizlik seviyesinde açıklamalıdır. Temizlik, isimden başlamaktadır.
• Fonksiyon, mümkünse tek bir iş yapmalıdır. Mümkün değilse bile fonksiyon tek bir iş yapmalıdır.
• Fonksiyon çok uzun olamamalıdır. Bir fonksiyonu okurken afedersiniz skrol yapmak gerekiyorsa,  o fonksiyon hemen parçalanmalıdır.21″ monitörde tek fonksiyon içine skrol gerektirecek kadar kod yazmak hol değildir.
• Fonksiyon pahalı bir olgudur. Bu sebeple fonksiyonun tekrar kullanılacağı düşünülmelidir.
• Yazılan bir fonksiyon, makine için değil insan için yazılır. Fonksiyon makine üzerinde çalışacak diye bir tek makinenin anlayacağı şekilde yazmak kalite ve anlaşılabilirlik kaybına sebep olur. Kod çalışmak zorunda olduğundan makine zaten onu anlayacaktır. Asıl mesele, insanın anlayacağı şekilde kod yazmaktır.
• Fonksiyon, dağıtılmadan önce doğrulanmalıdır ki kullanan kişilere aktarılmasının bir manası olsun.
• Kolaya kaçılıp, afedersiniz kötü kod, yorum satırlarıyla sıvanmamalıdır. Yorum satırları geçici iken, fonksiyonun kendisi kalıcıdır. Madem ki yorum satırı yazılabiliyor, ondan önce fonksiyonun kendisi temiz yazılmalıdır. Kod yazarak yapılamayacak şeyler, yorum satırları ile yapılmaldır.
• Bir fonksiyonun adında -meclisten dışarı- “ve(and), veya(and), oyleyse(then)” gibi kelimelerin geçmesi, o fonksiyonun birden fazla iş yaparak dünyayı kurtarmaya çalıştığını göstermektedir. Bu çok yanlıştır. Dünyayı kurtarmak  bir takım işidir. Bu fonksiyonlar derhal parçalanmalı ve temizlenmelidir.
• Bir fonksiyonu her kullanan kişi, o fonksiyonun tepesindeki yorumları değil, bizzat ismini görecektir. Yorum satırını görebilmek için fonksiyonun implementasyonunu açmak gerekmektedir. Bu, orta çağdan kalma bir işkence yöntemidir ve yapılmamalıdır. Reçete olarak, temiz, yaptığı işi ismiyle anlatan fonksiyonların yazılması şifa verecektir.
• Bir yazılımdaki tüm isimler, derleyici tarafından adres sembollerine çevirileceğinden, uzun ve derdi açıkça anlatan fonksiyon isimleri seçmek hiç kimseye zarar vermeyeceği gibi yazarın yaptığı işin kalitesini artıracaktır. Uzun isimli fonksiyon, kısa isimli fonksiyondan daha fazla bellek tüketmeyeceğinden eli korkak alıştırmanın lüzumu yoktur.

Maddeler bunlar. Şimdi kalem kalem bu başlığın önemli konularına değinelim.

Anlaşılabilirlik ve Modülarite

Hiç laf kalabalığı yapmadan, somut örneklerle mevzuya dalacağım. Zaten eski bir ahitte yazdığım bir örneği sizlerle bu perspektifte paylaşacağım.

Kötü Örnek:

Yukarıdaki rezil kodu hatırlarsınız. Bu tür kodlama yüzünden nice çok da olumlu yorulmlar alınmayacağı anlaşılmakta. Bir kere fonksiyonun adından “Ve” yazıyor. Bu fonksiyon dünyayı tek başına kurtarma gayretini, belki iyi niyetle ancak saf bir cehaletle göstermektedir. Cehalet kötüdür. Fonksiyonun adı hele iyice faciadır çünkü C dilini az çok bilen herkes bu fonksiyonun iki değeri toplayarak, bellekte bir yerlere yazdığını anlayabilecektir. Asıl soru bu işin neden, ne zaman, ne amaçla yapıldığıdır ki bu da gerçeğin altındaki hakikatin ta kendisidir.

Bir diğer şık olmayan davranış ise fonksiyon isminin Türkçe, yorumların ise Almanca + İngilizce olmasıdır. Bu yorumları kimse – belki İlber Ortaylı hariç – anlayamayacaktır (İlber Hoca da yorumları anlasa da kodu anlayamayacaktır). Dolayısıyla kodda tek bir insan dili tercih etmek daha hoş olacaktır.

Güzel Örnek:

Bu yukarıdaki kod da tanıdık. Ama ben kodu yeni görmüş gibi, “aaa ne güzel kod O_o” demek istiyorum. Paralel evrenin, bu kodu içeren, pek de ücrada kalmamış bu güzel köşesinde, kötü örnek kodunda yapılan işler bu defa çiçek gibi tertemiz bir şekilde, amme hizmeti bilinci ile yapılmıştır.  Kötü örnekteki kod derin kod olduğundan ne iş yaptığı bilinmemekte idi. Güzel örnekteki kod temiz kod olduğundan, kodun aslında ticaret işleri ile uğraştığı anlaşılmaktadır.

Gönderilecek veri serileştirilmek zorunda olduğundan, union kullanılarak +1 mühendislik puanı kazanılmıştır.

Değişken adları da mevzu hakkında çok sayıda açık bilgiyi, yazılım tutkunlarının hizmetine sunmaktadır. Bu kodu okuyunca u16BazUcretTL’nin TL cinsinden, 65536 TL’den küçük bir meblağ olduğu anlaşılmaktadır. Bu da, kodlamada şeffaflık ve temizliktir.

Kötü kod, kötülükle sıkı bağlar kurmuştur. Seri porttan veri gönderme işi er ya da geç başka yerlerde de kullanılacağından, kötü örnekteki yapıda kopyala yapıştır yapmak gerekcektir ki bu tekrar kullanılabilirlik kavramından çok uzaktır. Güzel örnekte ise bu işi yapan bir fonksiyon, ayrı bir bireydir ve tekrar kullanılabilir yapıdadır. Yani benzetme yapılacak olursa; hem dünyası, hem ahireti güzeldir.

Rekürsif Fonksiyonların Kullanımı

Mümkünse kullanmayalım efendim. Stack derinliği sabit olmayan rekürsif fonksiyonlar, gömülü sistemlerde kullanılmamalıdır. Zaten ters gidebilecek bir sürü şey varken neden bir şey daha ekleyelim ki?

Sayın muhterem… Eveeeet, bir programın daha sonuna geldiik.

Şimdi devam!