Temiz Kod Kavramı Nedir? Kodumuzu Nasıl Temiz Hale Getirebiliriz?

Teknolojiden, sektör farketmeksizin; okunabilir, temiz ve anlaşılır olarak kod yazabildiğimizde temiz kod yazmış oluruz.

Robert Martin, yazmış olduğu ve benim de bu yazıda çoğunlukla faydalandığım Clean Code kitabına “Bu kitabı iki sebepten okuyorsunuz; birincisi, programcı olmak istiyorsunuz. İkincisi ise daha iyi bir programcı olmak istiyorsunuz. İyi, bizim iyi programcılara ihtiyacımız var.” (Martin, 2009, p.1) sözleriyle giriş yapmaktadır.

Temiz Kodun Özellikleri
  •          Verimlidir
  •         Okunabilir
  •          Test edilebilir
  •         Sürdürülebilir
  •          Sadedir
  •         Tekrar içermez

Kötü kodu inceleyip anlamaya çalışırken harcayacağımız zaman artarsa, verimimiz de ters orantılı olarak azalacaktır. (Martin, 2009, p.4)

Neden Kötü Kodlama Yapıyoruz
  •          Dar zamanlı teslim süreleri
  •         Gereksinimlerin değişmesi ve kodumuzun bu değişime ayak uyduramaması
  •          Müşteri baskısı
  •          Projenin çabuk bitmesi için aceleci kod yazmamız
  •          Bilgi eksikliği
Temiz Kod İçin Dikkat Edilmesi Gereken Konular

Aşağıdaki konulara dikkat ederek kodumuzu temiz bir hale getirebiliriz.

  • İsimlendirme
  • Metotlar ve Sınıflar
  • Yorumlar
  • Formatlama
  • Hata Yönetimi
  • Refactoring
İsimlendirme

İsimler, bir yazılım projesi için birçok anlam ifade eder. Sınıf, metot, değişkenleri, kaynak dosyaları gibi öğeleri isimlendiririz.

      Anlaşılır olmalıdır.
İsimlendirme yaparken anlaşılır olmalı, anlaşılırlığı önleyecek kısaltmalar yapmamalıyız.

      Amacını ortaya koymalıdır.
Yaptığımız isimlendirme, amacını ortaya koymalıdır.

      Telaffuz edilebilen isimlendirme
Eğer telaffuz edilmesi zor bir isimlendirme yapmışsak, o kod üzerinde tartışılması çok zor olacaktır. İfade edemediğimiz için verim düşecektir.

      Aranabilen isimlendirme
Eğer tek karakterli bir isimlendirme yaptığımızda, o karakterde bir sürü veri getirecektir ve aradığımızı bulmak çok zaman alacaktır. Tek karakterli isimlendirmeleri metotlarda yerel değişken olarak döngülerde kullanmamız daha akıllıca olacaktır. Eğer bir değişken ya da sabit bir kod bloğunda birden fazla kullanılacaksa, arama dostu bir isim vermek en iyisidir.

      Member Prefixes
Alt çizgi koyarak isimlendirme yapmamıza gerek yok, isimlendirme yaparken çok uzun isimlendirme zaten yapmayacağız.

      Interface isimlendirme
Interface isimlerinin başına I eklememiz gerekir. Örnek: IOgrenci

      Sınıf İsimlendirme
Sınıf isimleri isim olmalıdır. Fiil olmamalıdır. Örnek: Araba, Ogrenci

      Metot İsimlendirme
Metot isimleri fiil olmalıdır. Örnek: GetBookById(), ToplamaYap()

      İsimlendirmede Kelime Oyunu Yapılmamalı
İsimlendirme yaparken mizahtan uzak durulmalıdır. Kültürel farklılıktan ve yazdığımız kodu inceleyecek yeni bir kişi için anlaşılması zor olacaktır.

      İsimler Tek Amaçlı Olmalıdır
Verdiğimiz isimler iki farklı amaç için olmamalıdır. Aynı ismi veremediğimiz için sonuna harf veya sayı ekleriz bu da kod kalitesini düşürür.

Kötü İsimlendirme Örnekleri
Küçük l (Lüleburgaz’ın L’si) ya da büyük O kullanmaktır. Çünkü görünüşte bir ve sıfıra benzerler.

int a = l;
if (O == l)
    a = O1;
else
    l = 01;


Kötü Kod                                                                                              Temiz Kod  

int wd;                                                       int workingDay;
//working day
int aveSpe;                                                   int averageSpeed;
//averageSpeed
class AEFon                                                   class Fon
{                                                             {

}                                                             }
Metotlar
  • Metotlar çok fazla satır içermemeli ve refactoring yaparak kısaltılabildiği kadar kısaltılmalıdır. İdeal olarak en fazla 20 satır içermelidir.
  • İç içe döngü en fazla iki seviye olmalıdır. İf-else bloklarının içi bir metoda alınarak tek satıra düşürülebilir.
  • Bir metot, tek bir iş yapmalıdır. Tek bir sorumluluğu olmalıdır.
  • Switch blokları N tane iş yaparlar, mümkün olduğunca kaçınılmalıdır, abstract class / metot kullanılır.
  • Do not Repeat Yourself – Bir metot başka yerde tekrar etmemelidir.
  • Bir fonksiyon üçten fazla parametre içermemelidir. Parametre sayısı artıyorsa, parametre objesi oluşturmalı, parametreler bu sınıf ile geçirilmelidir.
  • Metotlardan hata kodu dönmemesi adına Exception – Hata Yönetimi yapmak tercih edilebilir. Try/Catch blokları fonksiyonlara dönüştürülmeli, blok sadeleştirilmelidir.
  • Sınıf içinde bir fonksiyon diğerini çağırıyorsa, çağrılan fonksiyon çağıran fonksiyonun aşağısında olmalı. Kodu daha sıralı olarak takip edebiliriz.
  • Sınıf içinde bir fonksiyon diğerini çağırıyorsa, çağrılan fonksiyon çağıran fonksiyonun aşağısında olmalı. Kodu daha sıralı olarak takip edebiliriz.
 Yorumlar

      Kötü bir kod için yorum yapacağımıza o kodu yeniden yazmalıyız.
      Ne olduğunu değil, nasıl ve neden olduğunu açıklamalıyız. Ne olduğunu kodumuz açıklıyor.
      Yorum yazmamızın amacı kodda kendimizi ifade edemediğimiz noktaları ifade etmektir.

 Kötü Kod

 
 //Check to see if the employee is eligible for full benefits
 if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

Temiz Kod

if (employee.isEligibleForFullBenefits())

    Legal Comment –Yasal sebeplerden dolayı kodda kesin yorumlar yazmamız gerekir. Örneğin telif hakkı (copyright) ve yazarlık (authorship) durumları gereklidir ve her kaynak dosyanın başına böyle bir yorum koymak mantıklıdır. Tüm şartlar ve koşulları yorum içine koymaktansa, mümkünse standart bir lisans ya da dış bir dokümana referans tercih edilmelidir.

 Örnek:     //Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
                  // Released under the terms of the GNU General Public License version 2 or later.

      Versiyon geçmişini yazmamıza gerek yok.
      Geliştiriciyi çalıştırılacak kodun sonuçlarına karşı uyarmak gerektiğinde yorum kullanılabilir.
·       
       TODO Yorumları: Kodda yapmak istediklerimizi //TODO şeklinde yorum olarak yazabiliriz. TODO yorumları unutulmamak şartıyla eklenebilir. Aynı zamanda programcıların yapmaları gereken ancak o anda bazı sebeplerden ötürü yapmadıkları işler için yararlıdır. Kullanımdan kaldırılan bir özelliği silmek için hatırlatıcı olabilir, birilerinin daha iyi bir isim düşünmesini isteyebiliriz ya da başka birilerinin probleme göz atması için bir rica olabilir. TODO ne olursa olsun, sistemde kötü kod bırakmak için bahane değildir.

Örnek:  


 
// TODO-MdM these are not needed
// We expect this to go away when we do the checkout model

protected VersionInfo makeVersion() throws Exception

{
     return null;
}
            
       Kodu okuyarak anlayabileceğimiz şeyler için yorum yazılmamalıdır. Gereksiz kalabalık yaparlar.
       Yanlış bilgi içeren, yanlış yönlendiren yorumları temizlemeliyiz.
       Kullanmayacağımız kodları yorum içerisine almamalıyız. Yoruma alınmış kod bırakılmamalıdır.

 Formatlama
  •          Okunabilir olması önemli
  •          Alakalı metotlar 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 kaydırmaya gerek duyulmamalıdır.
  •          HTML içerisinde CSS kodu bulunmamalıdır. Ayrı bir dosya içerisinde tanımlanabilir.
  •          HTML kodlarında uygun girintiler olması gerekir. Bu kodun formatı açısından yararlıdır.
  •          İki metot arasında boşluk olması okunabilirliği arttırır.
Sınıflar
  • Sınıflar küçük olmalı, satırları fazla olmamalıdır.
  • Sınıflar ilk önce değişkenlerle başlamalıdır. Statik değişkenlerle başlamalıdır. Daha sonra metotlar gelmelidir.
  • SRP prensibine uyulması gerekmektedir.
Hata Yönetimi

Bir uygulamanın çalışması sırasında istenmeyen durumlar, hatalar ortaya çıkar ve programın akışını durdurur. Bu hatalar; programı yazan kişiden programı kullanan kişiye kadar çeşitli kaynaklardan ortaya çıkabilir. Yukarıdaki kaynaklardan dolayı oluşan istenmeyen durumları kontrol etme işlemine Exception Handling - Hata Yönetimi denir. 

Hata Yönetimi'nde amaç programın akışının kesilmesini engellemek ya da hataların analizini yaparak kullanıcıyı bilgilendirmektir. Bu şekilde kullanıcı yanlış bir işlem yaparak hata almayacaktır.

Refactoring

Dönem dönem yazdığımız kodları gözden geçirip gerekli yerleri refactor etmeliyiz.

Refactoring:Kodu temiz bir hale getirebilmek için yazılımın işlevlerini, davranışlarını değiştirmeden tasarımı üzerinde yapılan küçük değişikliklerdir. Yazılmış olan kodun elden geçirilmesi, farklı yerlerde tekrar eden kod bloğunun kaldırılması, kaliteli yorumlar yazılması, isimlendirmelerin düzenlenmesi işlemleri refactoring’e örnektir.

Birim Test

Yazdığımız metotların çalışıp çalışmadığını test edebilmemizi sağlayan bir test çeşididir.

Faydaları
  • Kodumuzu tekrar tekrar test edebiliriz.
  • Canlıya çıkarmadan önce hatayı yakalayabiliriz.
  •  Kodun davranışını değiştirmeden güvenle refactor edebiliriz.
  •  Kodun kalitesine odaklanmamızı sağlar.
  •  Doğru ya da yanlış olarak iki farklı sonucu olduğu için analiz etmemiz daha kolay olur.

 Kaynakça

Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice Hall.



















































Yorumlar











Yorum Gönder