Genel

Anlamlı İsimlendirmeler

Bir çok kod parçası yazabilir, projeler geliştirebiliriz. Fakat yazdığımız kodu sadece biz anlıyorsak, burada sorun vardır. Fonksiyonundan, sınıfına, parametresinden, paketine herşeyi doğru bir isimlendirmeyle anlatmalıyız.

İsimlendirme zaman kaybettiriyor gibi görünse de gerçekte doğru isimlendirme çok zaman kazandırıyor. Aşağıdaki örnekte misal “d” ne işe yarıyor. İyi bir kod açıklama satırına ihtiyaç duymamalı. Tartışılabilir bir konu fakat bende bunu savunuyorum. Kitaptaki iyi isimlendirmeler :
Aşağıdaki kod bloğunu ilk bakışta okuyabildiniz mi ? Bu kodu çalışma arkadaşınız yazsaydı ne derdiniz ? Sıkıntı belli kod basit fakat açık değil.
  • theList ‘te ne var ?
  • theList’in ilk elemanı neden önemli ?
  • 4 ‘ün bize anlatmak istediği şey ne ?
  • Dönen liste ile ne yapabilirim ?

Kodun mantığını değiştirmeden, düzeltirsek. Ne değişti ? Oyunun mayın tarlası olduğunu düşünürsek, metot ismi anlamlandı, theList bize oyun tahtası olduğunu anlattı, 4 aslında işaretlenmiş bir değer, 0 ise bize lokasyonu ifade ettiğini anlatmaya başladı. İyi kod kendini anlatır.

Benim en çok yaptığım hatalardan birine gelelim. Liste isimlendirmeyi nasıl yapıyorsunuz ? Ben list’i accountList gibi isimlerle tanımlıyorum. Kitap zaten bunun List olduğunu ve List gibi bir ifadeye ihtiyacın olmadığını söylüyor. Accounts, accountGroup gibi tanım yap diyor.

XYZControllerForEfficientHandlingOfStrings ve XYZControllerForEfficientStorageOfStrings gibi ufak değişiklikler içeren isimlendirmeler vermemeliyiz. 1 ile l ya da 0 ile O ‘nun karıştığını unutmamamız gerekiyor.

Bir scope’ta aynı isimden 2 değişken tanımlayamayacağımıza bu değişkenler arasında kelime oyunu yaparız, yapmamaya çalışın. Eğer isim farklıysa anlamda farklı olmalıdır. Örneğin a1,a2 gibi isimlendirme yerine source destination gibi isimlendirme kullanın.

Farklı isimlerde sınıflarınız varsa anlam olarakta farklı olmasına özen gösterin. ProductInfo ya da ProductData gibi farklı 2 sınıf anlam olarak çok yakındır ve projeyle ilgilenen kişiyi zorda bırakabilir.

nameString ya da todayDate gibi isimlendirme yapmamak gerekir, name zaten float olamaz ki. Today normalde date olması gerek hadi değil bunu zaten çağırırken tipinden anlarız. Bunun gibi durumlarda değişkenlere Variable, Int vs eklemeye gerek yok.

Misal aşağıdaki kod’tan ne anlarsınız ? genymdhms ‘yi generationTimestamp olarak mı okudunuz ? Kısaltmaları dikkatli kullanmaya özen göstermek gerek. 2 nedeni var, biri kodun okunabilirliğine ciddi zarar veriyor, 2. ‘si ilk kodu sesli okuyup arkadaşınıza anlatmaya çalışın.

İsim olarak yapmış olduğunuz tanımlama daha sonrasında yapılacak aramaylada kolay ve rahat bulunmalıdır. Eğer tek harf kullanıcaksan local değişkende kullan fakat bir sabitte vs anlamlı isimler kullan.

Kitapta aslında sabit ‘i neden kullanmak gerektiği, neden işlemleri bölmemiz gerektiğini aşağıdaki kod parçacığında anlatıyor. Kod aynı kod, fakat isimlendirme koda çok ama çok fark katıyor.

Sınıf İsmi tanımlanırken isim Customer, WikiPage, Account, AddressParser gibi “isim” ya da isim tümcesi olmalıdır. Sınıf adında Info, Manager, Processor, Data gibi sözcüklerden kaçınılmalıdır.

Metot ismi tanımlarken fiil ya da fiil tümceciği olacak şekilde tanımlanmalıdır. Örneğin deletePage, save, postPayment gibi isimler kullanılmalıdır. Pojo sınıflar içinde get, set ve is prefix ‘i içeren javabean standartına göre isimlendirmeler tercih edilmelidir.

Projede her zaman bir kelime seçmeye özen gösterin. Misal bir yerde fetch, bir yerde get, farklı bir yerde retrieve kullanmayın.

Address sınıfınız firstName, lastName, street ve state değişkenlerine sahip olsun. Address sınıfını okumasaydınız state ve street değişkenlerinin hangi sınıfa ait olduğunu düşünürdünüz ? addrState gibi sınıf adını belirterek, gereksiz bağlamdan kaçacak şekilde geliştirmeliyiz.

Kitabın bu bölümünde son olarak burada yazılanları uyguladıkça kodun kalitesinin artacağını belirtiyor. Önemli olan kodun çalışabilirliğinden ziyade ekipçe çalışılan projelerde arkada bırakılan kodun başkaları tarafından anlaşılması daha önemlidir.

Son Söz :

Herkes derleyicinin anladığı kodları yazabilir fakat bir insanın anladığı kod yazmak bunu yazmaktan daha zordur.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir