10 Yazılımcı Yalanı, Kod Okuma, Commentlar

Korkutucu bir makale - The Top Ten Lies of Engineers - firma CEO' suna bu linki göstermeyin, şunlar favorilerim oldu;

• This time we got it right
• This code is so bad it would be faster to write it all from scratch than debug and expand the current shipping code
• It works on my machine (kabul ediyorum acayip bug reportlarında bende bunu yapıyorum)
• I'll comment the code, so that the next person can understand what I did.

Son yalanda aslında dikkat çekici bir konu. Eğer ki bir framework, library ya da benzeri bir şey geliştirmiyorsanız bir de .NET, Java, Delphi gibi daha üst seviye bir dilde kod geliştiriyorsanız çok fazla comment' ın pek bir anlam ifade etmediğine inanıyorum. Önemli olan kodun mantıklı olması, akışın doğru olması (bkz: spagetti kod - inanmıyorum tr wikipedia a bir kaynak olarak link verebildim!)

Kodu en okunaklı kılan şey ise muhtemelen değişken isimleridir, class isimleri, sayfa isimler, veritabanınıdaki kolon isimleri. Tabii ki günün sonunda illa ki kod sayfasına 10 satır comment yazdığımızı varsayıyorum.

Function, Prosedür, Class gibi kodlarda illa ki gerekli açıklama, fonksiyonun ne için geliştirildiği, ne kabul ettiği, ne döndürdüğü varsa özel durumlarının (recursive mi?, beklenenden çok daha fazla memory harcayabilir mi?, Parametre X yerine Y verirsen patlayabilir mi?) şiddetle dokümante edilmelidir.

Eğer ki OO bir dilde geliştirme yapıyorsanız kesinlikle class / function ve dilinizin, IDE' nizin 3rd party toollarınızı desteklediği şekilde bir dokümantasyon standardına uymalısınız. Bu sonradan size de büyük kolaylık sağlayacaktır.

VS 2005 üzerinden çalışanlar için Class Designer kodun daha rahat anlaşılması konusunda çok yardımcı olabilir hatta seksi bir programınız varsa buradan kendinize bir poster baskısı alabilir, bilgisayarınızın arkasına asabilir ve pis geek karizması yapma hakkı kazanabilirsiniz.