Okunabilir Kod Sanatı — 1

Published in

Bilişim Hareketi

5 min readAug 27, 2017

Programcılar olarak, çok çirkin ve hatalı kaynak kodları gördük ve bunlar bizim başımızı çok ağrıttılar. Son beş yıldır kitabın yazarları yüzlerce “kötü kod” örnekleri incelediler. Çıkan sonuç şu; başkası kodunuza baktığında en kısa zamanda anlayacağı kodlar yazmanız gerekiyor, bu başkası kendiniz olsa bile.

Bu yazı Art of Readable Code kitabından alıntıdır. Orjinal halini buradan alabilirsiniz.

Kodu Ne Daha İyi Yapar?

Birçok programcı, programlama kararlarını hislerine ve sezgilerine göre alırlar. Şöyle kod yazmak,

Şöyle kod yazmaktan daha iyidir, ki kodlar aynı işi yapar.

Bazı durumlarda, bu karar daha zordur.

İlki mi daha iyidir, yoksa ikincisi mi? Handi kodun daha iyi olduğuna nasıl karar veririz?

Okunabilirliğin Temel Teoremi

Birçok kod örneği incelendikten sonra, şu karara varıldı,

Kod, başkaları tarafından en az zamanda anlaşılsınlar diye yazılmalıdır.

Bununla ne kastediyoruz? Çalıştığın yerdeki bir arkadaşını alıp kodunu incelettiğin zaman, kodu okuyup anlaması ne kadar sürüyor?

Anlamak derken, çok iyi anlamayı kastediyoruz. Kodu anladıktan sonra kod üzerinde değişiklik yapabilir, kodda hata ayıklayabilir ve kodun geri kalanıyla etkileşiminin ne olduğunu çözebilir hale gelmesi gerekiyor.

Kodun anlaşılması kimin umrunda, benden başka onu kullanan yok ki, diye düşünebilirsiniz. Projede tek adam bile olsanız, altı ay sonra dönüp baktığınızda kodu anlaşılmaz bulabilirsiniz. Başkalarının da ileriki zamanlarda projeye katılmayacağından emin olamazsınız.

Küçük Her Zaman İyi Midir?

Genellikle, daha az kod yazmak daha iyidir ama her zaman az olan iyi olacak diye bir şey yok. Örneğin,

İlk ifade daha kısa olmasına rağmen, ikinci ifadeden anlaşılması daha zordur.

İsimlere Bilgileri Paketleyin

Bir değişken, fonksiyon ya da sınıf adlandırılırken aynı prensip geçerlidir. Açıklayıcı güzel isimler olmalıdır.

Bu konuyu altı başlığa ayırabiliriz,

Özel kelimeler seçin
Genel isimlerden kaçının
Soyut isimler yerine somut isimler kullanın
Soneklerle veya öneklerle isimlere ekstra bilgiler ekleyin
İsmin ne kadar uzunlukta olması gerektiğine karar verin
Ekstra bilgi paketlemek için isim formatlamayı kullanın

Özel Kelimeler Seçin

Örneğin, “get” kelimesi oldukça geneldir,

def GetPage(url):
   …

get kelimesi çok bir şey söylemez. Sayfayı nereden getirecek, lokal önbellekten mi, veritabanından mı ya da İnternetten mi? Eğer İnternetten ise, daha genel bir isim doğru olabilir, FetchPage() ya da DownloadPage().

BinaryTree sınıfının örneği,

class BinaryTree{
    int Size();
    ...
};

Size() metodunun ne dönmesini bekleriz? Ağacın yüksekliğini mi, düğüm sayısını mı, ya da bellek ayakizini mi?

Height(), NumNodes() ya da MemoryBytes() gibi özel isimler daha iyi olur.

Daha Renkli İsimler Bulun

Bu konu hakkında arkadaşlarından yardım isteyebilirsin.

Daha açık ve kesin olmak, tatlı olmaktan daha iyidir.

Genel İsimlerden Kaçının

tmp, retval ve foo gibi isimler çok geneldir, bunlardan kaçnın. Örnek bir JavaScript fonksiyonu,

retval değişkenini daha iyi bir isim bulamadığın için, kullanımı seni cezbedebilir ama çok fazla anlam ifade etmez.

Bu durumda, sum_squares(kareleri toplamı) daha iyi uyabilirdi. Kodu yanlışlıkla şöyle yazsaydınız, hataları bulmak da daha kolay olurdu.

sum_squares += v[i]; // karelerin toplamını tutuyor ama karesini  //hesaplamıyor, burada hata olabilir.

Bazı durumlarda, genel isimler bir anlam taşıyabilir,

tmp adında bir değişken kullanmak buraya çok iyi uymuş. Değişkenin tek amacı geçici kullanılmak içindir. Bazı durumlarda ise tmp kullanmak tamamen tembelliktir,

Burada da tmp değişkeni kısa ömürlü olsa da, user_info gibi bir isim kullanmak daha açıklayıcı olurdu.

Soyut İsimler Yerine Somut İsimler Kullanın

Değişken, fonksiyon ya da başka bir elemanı isimlendirirken somut isimler kullanın.

Örneğin DISALLOW_EVIL_CONSTRUCTORS,

Google kod tabanından bir örnek. C++’da, sınıfınız için kopyalama yapılandırıcısı(copy constructor) ya da atama operatörü(assignment operatörü) tanımlamadığınız zaman, varsayılan size sağlanır. Kullanışlı olmasına rağmen, bu metodlar kolaylıkla bellek sızıntılarına veya farklı hatalara yol açabilir.

Sonuç olarak, Google genel bir kabul ile makro kullanarak, bu şeytan(evil) yapılandırıcıları yasaklamak istemiş,

DISALLOW_EVIL_CONSTRUCTORS ismi çok iyi bir isim değil. Gerçekten ne yapmak istediği anlaşılmıyor.

Bu isim belki yıllarca kullanıldı ama sonradan daha düzgün bir haliyle değiştirildi.

#define DISALLOW_COPY_AND_ASSIGN(ClassName) ...

İsimlere Ekstra Bilgiler Ekleyin

Değişkenin adını, küçük bir yorum gibi düşünün.

Onaltılık sayı düzeninde bir değişken tuttuğunuzu düşünün,

string id; // Örnek: "af84ef845cd8"

id yerine hex_id demeniz daha iyi olurdu.

Ölçümle alakalı bir isimlendirme yapıyorsanız, birimini de değişkene eklemek faydalı olur.

İlk kodla ilgili bir yanlışlık gözükmüyor ama hatalı çalışır, çünkü getTime() milisaniye cinsinden değer döner.

_ms soneki ekleyerek kodu daha açık hale getirip, buradaki hataları önleyebiliriz.

İsim Ne Kadar Uzunlukta Olmalıdır?

İyi isim seçerken, çok fazla uzun olmamasına özen göstermelisin. Şöyle bir isimden kimse hoşlanmaz,

newNavigationControllerWrappingViewControllerForDataSourceOfClass

Uzun isimi, hatırlamak daha zordur. Bu demek değildir ki tek kelimelik adlandırma yapalım. Değişkenin ne için kullandığına göre ismimizi seçmeliyiz.

if (debug) {
    map<string,int> m;
    LookUpNamesNumbers(&m);
    Print(m);
}

m değişkeninden herhangi bir bilgi anlaşılmasa da, çok sorun olmaz, çünkü bütün kod if bloğu içindedir.

Bununla birlikte, m bir sınıfın global değişkeni olsaydı işler o zaman değişirdi.

Günümüzde, IDE’lerin kod tamamlayıcı özelliğinin çok gelişmesiyle beraber uzun isimlendirme yapmak artık daha kolay bir hal almıştır.

Anlam Taşıyan İsim Formatlaması Kullanın

Google C++ açık kaynak kodlarında karşılaştığımız bir örnek,

Farklı varlıklar için farklı isimlendirme formatları kullanılmış, sanki kod renklendirmesi gibi. Bu kodu daha okunur kılar.

kMaxOpenFiles değişkeni büyük harfli macro isimlerinden(EXAMPLE_MACRO) ayırt etmek için bu şekilde kullanılmış.

Sınıfın üye değişkeninin de sonuna alt tire(_) eklenmiş. stats.clear() gibi bir kod gördüğünüzde, stats değişkeninin sınıfa ait olup olmadığını hemen anlarsınız.

Estetik

İyi kaynak kodu, göze kolay gelmelidir. Şöyle bir kod düşünün,

Açıkça görülüyor ki, ikincisi gibi kodu düzenlemek çok daha okunulabilir kod ortaya çıkarıyor.

İ. K. Notu: Günümüzde artık kod formatlama çok kolaylaştı. Şirkette herkesin benimseyebileceği ortak bir kod formatı tanımlayıp kullanmak gerekiyor.