Comments : “Kötü kodun yorumu olmaz, yeniden yaz !” Kitap yorum satırında açıklama yapmaya karşı çıkıyor. Nedeni ise eski, güncel olmayan ya da yanlış yorumlayan yorum satılarlarının kod üzerinde anlamsızlığa neden olduğunu belirtiyor.

Yorum satırı kısaca sizin kötü olan kodunuzu gizlemek için danıştığınız işlemler olduğunu anlatıyor. Her yorum satırı yazdığınızda kodunuzdaki değişken, metot, sınıf isimlendirmelerinde yetersiz bir yerler olduğunu düşünün.

Gerçek sadece tek bir yerde bulunabilir: kod. Yalnızca kod size gerçekten ne yaptığını söyleyebilir. Gerçekten doğru bilginin tek kaynağıdır. Bu nedenle, yorumlar bazen gerekli olsa da, bunları en aza indirmek için önemli miktarda enerji harcayacağız. Hangisi daha anlaşılır ?

Faydalı bir yorum satırı nasıl olmalı ? Regular expression ifadesindeki kullanımı iyi olabilir, yine de sınıf olarak adı anlaşılır şekilde tutmak ve metotla destekleyerekte kodu anlaşılır kılabiliriz.

Bazen bir kodu çalıştırmadan önce işlemler yapılması gerekmektedir. Test için bir kodu çalıştırmadan uyarı verilecekse @Ignore kullanın. TODO ise bir kodta yapılacak işlemler için bıraktığımız notlardır. Kullanmakta sakınca olmaması ile birlikte arada göz gezdirmek oldukça iyidir

Kötü bir yorum satırı ise nelerden oluşur. Çoğunluğu aslında kötü yorum satırları oluşturuyor. Eğer bir işi yapıyorsan burada yorum satırı ile mırıldanma. Zaten senin yaptığın işi kodun anlatmalı. Gerçekten Catch bloğundaki yorum satırına yazar dışındaki birinin ihtiyacı var mı ?

Yakalama bloğundaki bu yorum ne anlama geliyor? Açıkça yazar için bir şey ifade ediyordu, ancak anlam o kadar da iyi gelmiyor. Görünüşe göre, bir IOException alırsak, bu, hiçbir özellik dosyası olmadığı anlamına gelir; ve bu durumda tüm varsayılanlar yüklenir. Ama tüm varsayılanları kim yükler? loadProperties.load çağrısından önce yüklendiler mi? Yoksa loadProperties.load istisnayı yakaladı mı, varsayılanları yükledi ve ardından bizim yok saymamız için istisnayı iletti mi? Yoksa loadProperties.load, dosyayı yüklemeye çalışmadan önce tüm varsayılanları yükledi mi? Yazar, yakalama bloğunu boş bıraktığı gerçeği konusunda kendini teselli etmeye mi çalışıyordu? Veya -ki bu korkutucu olasılıktır- yazar daha sonra buraya gelip varsayılanları yükleyecek kodu yazmasını mı söylemeye çalışıyordu ?

Tek çaremiz, neler olup bittiğini anlamak için sistemin diğer bölümlerindeki kodu incelemek. Sizi o yorumun anlamı için başka bir modüle bakmaya zorlayan herhangi bir yorum sizinle iletişim kuramadı ve tükettiği bitlere değmez.

Redundant Comments ile aslında kodu hızlıca göz gezdirip anlayacağımıza gereksiz olarak yorum satırıyla zaman kaybettiğimizi vurguluyor.

Zorunlu yorumlar, Her işlevin bir javadoc’u olması gerektiğini veya her değişkenin bir yorumu olması gerektiğini söyleyen bir kuraldır. Bunun gibi yorumlar sadece kodu karıştırır, yalanları yayar ve genel bir kafa karışıklığına ve düzensizliğe yol açar.

Tomcat içerisinde bulunan bir kod parçacığı ve içerisi çok fazla yorum satırı ile doldurulmuş.

Gürültü Yorumları, zaten kodta açıklanan bişeyi açıklamamaya çalışan kodlardır. Oldukça gereksiz.

Aslında benimde eklediğim ve kolaylığını düşündüğüm kodun kim tarafından eklendiği de kitap tarafından gereksiz yorum olarak görülüyor. Nedeni şu ki zaten bir versiyon kontrol sistemi kullanıyorsun ve herşey kayıtlı. Neden kodu kirletiyorsun. Catch, while, try nerede bittiğini yazdığımız yorum satırları da gereksizdir, günümüz ide’leri bu konuda gayet başarılıdır.

Eğer kodunda yorum satırına eklenmiş bir kodun varsa artık bunu da yapma. Sen zaten kullanılmayacağını biliyorsun, sil geç. Korkak alıştırma elini. Eğer kullanılmayacak ve gereksizse sil gitsin. Local history ya da vcs ‘ler ne güne duruyor, gerektiğinde bulursun.

Kodunla ilgili fazla bilgi içeren yorum satırları mı var, sil gitsin. Kimsenin işine yaramayacak..

Bu bölüm kısaca 1. bölümde işlediğimiz anlamlı isimlendirmeler ile kodu olabildiğince az bir şekilde yorum satırına (hatta hiç!) ihtiyaç duyacağını belirtiyor. Bölüm 5 ‘te görüşürüz. 🙂