C# Kod Standartları ve En İyi Programlama Teknikleri

[elektronikmuh]

1. Giriş
2. İsimlendirme ve standartları
3. Girintiler ve aralıklar
4. Doğru programlama teknikleri
5. Mimari
6. ASP.NET
7. Yorumlar
8. Hata ayıklama

Giriş

C# Kodlama standartlarının anlatıldığı 8 bölümlük serimize giriş yapmış bulunuyoruz.
Herkes birkaç aylık programlama eğitimi sonrasında kod yazar hale gelebilir. Kolayca çalışan uygulamalar ortaya çıkarabilir. Ancak işi doğru bir şekilde yapmak, daha fazla çalışma gerektirir.
Şuna inanmak gerekir ki programcıların çoğu “çalışan kod” değil “iyi kod” yazmak ister. “İyi kod” yazmak öğrenilmesi gereken gerçek bir sanattır.
“İyi kod” yazmanın tanımını herkes farklı bir şekilde yapabilir. Bence iyi kodun şu özellikleri taşıması gerekir.

• Güvenilir olamlıdır.
• Sürdürülebilir olmalıdır. Yani bakımı kolay olmalıdır.
• Verimli olmalıdır.

Birçok geliştirici kodun sürdürülebilir ve güvenilir olmasından çok, yüksek performanslı olmasını göz önünde tutar. Ancak uzun vadede (Yatırım açısından) verimlilik ve performans, güvenilirlik ve bakımdan sonra gelir. Yazdığınız kod güvenilir ve sürdürülebilir değilse, siz (veya şirketiniz) her defasında sorunların tespiti ve uygulamanın akışını anlayabilmek için çok fazla zaman harcamak zorunda kalacaktır. Unutmayın, yapılan her fazla mesainin ardında plansız yapılmış işler vardır.
Microsoft ASP.NET takımından Syn. Stephen Walter bir hikayesinde yazılım geliştirmeye ilk başladığı zamanlarda iyi yazılım için “Good software is software that works as you intended.” diyoru. Yani iyi yazılım istediğiniz gibi çalışan yazılımdır. Ancak daha sonraları büyük şirketlere girdiğinde geliştirilen yazılımın odak noktasının hızlı yazılım üretmek değil, yazılan kodun bakımının kolay olması olduğunu görüyor. Stephen Walter fikrini değiştiriyor ve “Good software is software that works as you intended and that is easy to change” diyor. Yani iyi yazılım bakımı kolay olan ve istediğiniz gibi çalışan yazılımdır diyor.
Serinin devamında isimlendirme ve standartları ile kodlama olaylarını örneklerle anlatarak devam ediyor olacağız.


İsimlendirme ve standartları

Serimizin ikinci bölümüyle yeniden birlikteyiz. Bu bölümde kodlama yaparken alan, özellik, sınıf gibi yapıların isimlendirmelerini yaparken dikkat etmemiz gereken noktaları konuşacağız.
İsimlendirme standartlarına giriş yaparken makale boyunca sıklıkla karşılaşacağımız Pascal Casing ve Camel Casing kavramlarından bahsetmemiz gerekiyor:
Pascal Casing: Kelimelerin ilk harfleri büyük geri kalan harfleri küçük yazılır.
Örnek:ProductName
Camel Casing: İlk kelimenin ilk harfi hariç kelimelerin baş harfleri büyük diğer harfler küçük yazılır.
Örnek:productName

• Sınıf adlandırmalarında Pascal Casing yöntemini kullanın.

• Metod adlandırmalarında Pascal Casing yöntemini kullanın.

• Değişken isimlerinide ve metod parametrelerinde Camel Casing yöntemini kullanın.

• Arayüz (Interface) isimlendirmelerini yaparken “I” ön ekini kullanın.(Ör: IProduct)

• Değişken isimlendirmelerinde Macar (Hungarian) notasyon tercih etmeyin. Önceleri programcıların değişken kelimeleri arasında kullandığı ”_” alt tire karakteri .net kod standartlarında tercih edilmez. (ÖR: String m_name;). Bunun yerine Camel Casing kullanılır.

• Değişkenler için anlamlı ve açıklayıcı kelimeler kullanın. Kısaltma kullanmayın.

İyi Kod:
string address
int salary
​

Kötü Kod:
string nam
string addr
int sal
​

• Tek karakterlik değişken işimleri (i, n, s gibi) kullanmayın. Bunun yerine index, temp gibi kelimeler kullanın. Ancak döngülerde iterasyon için kullanılan değişkenler bu durum haricindedir.

for ( int i = 0; i < count; i++ )
{
……..
}
​

• Lokal değişkenler için (_) alt tire karakterini kullanmayın.

• Değişken isimlerini C# anahtar kelimelerine benzer olacak şekilde seçmeyin.

• Mantıksal (boolean) değişkenlerin önünde (is) veya benzer ön ekler kullanın. (ör: private bool isFinished)

• UI elemanlarını birbirinden ayırabilmek için uygun bir önek kullanın.

Control	Prefix
Label	lbl
TextBox	txt
DataGrid	dtg
Button	btn
ImageButton	imb
Hyperlink	hlk
DropDownList	ddl
ListBox	lst
DataList	dtl
Repeater	rep
Checkbox	chk
CheckBoxList	cbl
RadioButton	rdo
RadioButtonList	rbl
Image	img
Panel	pnl
PlaceHolder	phd
Table	tbl
Validators	val

• Sınıfların (Class) bulunduğu fiziksel dosya isimleri sınıf ismi ile aynı olmalıdır. Örneğin HelloWorld sınıfı için dosya adı helloworld.cs veya HelloWorld.cs olabilir.

• Dosya isimleri için Pascal Casing kullanın.

Girintiler ve aralıklar

• Girinti yapmak için TAB tuşunu kullanın. Boşluk (SPACE) tuşunu kullanmayın.

• Yorum satırları kod satırlarıyla aynı hizada olmalıdır.

İyi Kod:

Kötü Kod:

• Süslü parantzler ( {} ) kodlar ile aynı seviyede olmalıdır.

• Gruplandırdığınız kod blokları arasında bir satır boşluk bırakın.

İyi Kod:

Kötü Kod:

• Sınıf içinde her bir metod arasında sadece bir satır boşluk olmalıdır.

• Süslü parantezler if, for gibi kodlarla aynı satırda olmamalı ayrı bir satırda olmalıdır.

İyi Kod:

Kötü Kod:

• Her operator ve parantezden önce bir boşluk bırakın

İyi Kod:

Kötü Kod:

• Birbiri ile alakalı kod parçalarını guruplamak için #region kodunu kullanın. Bu kod arasında kalan kodları kapatarak saklamak mümkündür.

• Private üye değişkenleri, metodları ve özellikleri dosyanın üst kısmında public olanları ise dosyanın alt kısmında tutun.

Doğru Programlama Teknikleri

• İçeriği çok uzun olan metodlar yazmayın. Bir metod 1 – 25 satır arası uzunlukta olmalıdır. Eğer 25 satırdan uzun bir metodunuz varsa bunu alt metodlara bölmelisiniz.
• Metod isimleri metodun ne iş yaptığını anlatır nitelikte olmalıdır. Niyeti belli etmeyen yanıltıcı isimler kullanmayın. Metod ismi açıklayıcı şeklide seçilirse metodun ne iş yaptığını belirten yorum satırları yazmamıza gerek kalmaz.

İyi Kod:

Kötü Kod:

• Yazılmış bir metodun tek bir işi olmalıdır. Metoda yaptıracağınız iş çok küçük olsa bile, tek bir satırlık olsa bile birmetoda birden fazla işi yüklemektek kaçının.

İyi Kod:

Kötü Kod:

• Değişken tiplerini System ad uzayındaki özel tipler yarine C# veya VB dillerine belirlenmiş standart değişken tiplerden seçin.

• Herzaman beklenmedik durumları göz önünde bulundurun. Örneğik iki değer alabilen bir değişkeniniz varsa bu değerler dışında bir durum olabileceğini göz önünde bulundurmalısınız.

İyi Kod:

Kötü Kod:

• Sayı değerlerini kod içine doğrudan gömmek (Hardcode) yerine Constant değişken olacak şekilde tanımlayın. Ancak constant değişkenler ilerde değiştirilme ihtiyacı duyacaksa kullanması önerilmez. Bunun yerine configuratin dosyaları veya veritabanları tercih edilir. Eğer bir değer hiç değişmeyecek değer alacaksa constant olarak tanımlayın. Örneğin pi sayısı gibi.
• String değişkenleri kod içine doğrudan yazmak yerine resource dosyaların kullanın.
• String değişkenleri birbiri ile karşılaştırmadan önce UpperCase veya LowerCase dönüşümü yapın. Bu sayede karşılaştırılan kelimeler yazım olarak aynı standarda getirilerek karşılaştırma yapılmış olacak. Yani “kelime” ile “KeLiMe” karşılaştırmasında hata olmaktan kutulmuş oluruz.

• String tiplerin boş olup olmadığı durumları test etmek için (“”) sınaması yerine String.Empty sınamasını kullanın.

İyi Kod:

Kötü Kod:

• Üye değişkenleri (members) kullanmaktan kaçının. Ortak bir üye değişkeni tüm metodlarda kullanmak yerine lokal değişkenleri gerektiği yerlerde tanımlayın ve diğer metodlara geçirin (parametre olarak). Bu sayede değişkenin hangi metod tarafından ne zaman değiştirildiğini takip etmek kolay olur.
• Gerekli yerlerde enum kullanın. Ayrık değerleri göstermek için string veya numaraları kullanmaktan kaçının.

İyi Kod:

Kötü Kod:

• Üye değişkenleri (members) public veya protected tanımlamayın. Bunun yerine bu değişkenlere özel özellikler (properties) tanımlayın.
• Olay yakalayıcılar (Event Handler) içerisinde direk iş yapıcı kodlar bulundurmak yerine Event Handler tarafından bir metodu çağırarak metoda iş yaptırın.
• Kod içinde fiziksel dosya yollarını (path) veya sürücü isimlerini asla elle yazmayın. Bunun yerine “application path” denilen uygulamanın göreceli yollarını kullanın.
• Uygulamanızın her zaman “C:” sürücüsünde çalışacağını farzetmeyin. Belki bir kullanıcı “D:” sürücüsünde veya sunucuda çalışacak olabilir.
• Uygulama başlatılırken, önce bir “öz dnetim” yaparak gerekli dosyaların olup olmadığını veya veritabanı bağlantılarının sağlanım sağlanmadığını test ederek kullanıcıyı uygun bir mesajla durumdan haberdar edin.
• Konfigürasyon dosyası yoksa uygylama varsayılan olarak bir dosya oluşturabilmeli.
• Konfigürasyon dosyasındaki bir ayar yanlış girlmişse uygulama bir hata fırlatmalı veya kullanıcıya doğru ayarın ne olması gerektiğini bildirmelidir.
• Hata mesajları kullanıcıya sorunu çözebilmesi için yardımcı olmalıdır. Örneğin “Veritabanı bağlantısı sırasında bir hata oluştu. Kullanıcı adı ve şifrenizi kontrol ediniz.” gibi.
• Bir dosya içinde birden fazla sınıf (class) bulundurmayın.
• Çok büyük dosyalar oluşturmaktan kaçının. Bir dosya içinde binlerce satır kod olmamalıdır. Bunun yerine ayrı dosyalarda küçük sınıflar (class) halinde çalışılmalıdır.
• AssemblyInfo dosyasına bilgileri tam olarak girin. Ad, soyad, şirket v.s gibi.
• Eğer bir veritabanı, file stream veya soket bağlantısı açtıysanız bu bağlantıyı finally bloğunda kapatın. Bu sayede kodunuz zaten açık olan bağlantıyı açmaya çalışıyorsunuz şeklinde hatalardan arınmış olur.
• Bir döngü içinde string nesnelerini işlemek zorunda kaldığınızda string yerine StringBuilder nesnelerini tercih edin. .Net’te String nesnesi garip bir şekilde çalışır. Bir stringe bir ekleme yaptığınızda eski string silinerek yeni bir nesne oluşturulur. Bu da pahalı bir yöntem olacaktır.

Aşağıda bu durumu yansıtan bir örnek mevcut:

public string ComposeMessage (string[] lines) { string message = String.Empty; for (int i = 0; i < lines.Length; i++) { message += lines ; } return message; }

StringBuilder nesnesinin kullanıldığı bir örnek ise şu şekilde olacaktır:

public string ComposeMessage (string[] lines)

{

  StringBuilder message = new StringBuilder();

 
  for (int i = 0; i < lines.Length; i++)
  {
     message.Append( lines[i] );
  }
 
  return message.ToString();
}

Mimari

Serimizin bu bölümünde mimariler konusuna kısaca değinilmektedir.

• Her zaman çok katmanlı (N-Tier) mimariyi tercih edin.
• Veritabanı bağlantılarını arayüzün bulunduğu katmandan (UI ) yapmayın. Her zaman veritabanı işlemlerini ve ilişkilerini barındıran bir veri erişim katmanınız bulunsun. Bu sayede bugün MsSQL server yarın Oracle veya Ms Access dosyasını kullanmanızda sorun olmayacaktır.
• Veritabanı hatalarını yakalamak için try-cache kullanın. Bu sayede connectionstring, sql komutu, stored procedure gibi yapıların hangisinde hata olduğu açığa çıkıyor olacaktır.
• Uygulamanızı gerektiği taktirde birçok projeden(assembly) oluşacak şekilde geliştirin.

ASP.NET

Serimizin bu bölümünde Asp.Net tarafında faydalı olabilecek birkaç ipucuna değinilmektedir.

• Session değişkenlerini kodun her tarafında kullanmayın. Yazdığınız sınıflarda ki metodlarda oturum değişkenlerine erişmek için kullanın. Bir sınıf System.Web.HttpContext.Current.Session ile oturum değişkenine erişebilir.
• Session değişkenlerinde çok büyük veriler saklamayın. Büyük verilere sahip olan session değişkenleri çok kullanıcılı sistemlerde sunucu hafızasını olumsuz etkileyecektir.
• Sayfaların tasarım kısmında stil dosyalarını kullanın. Font isimleri ve font büyüklüklerini sayfa kodları içine eklemeyin. Uygun stil dosyalarını kullandığınızda font büyüklüklerini değiştirmek için bakacağınız yer stil dosyası olacaktır.

Yorumlar

Anlamlı ve açıklayıcı yorum satırları kodu daha anlamlı kılar ve bakımı kolaylaştırır. Bu noktada dikkat edilmesi gereken hususlar şunlardır.

• Yazılan her koda yorum satırı eklemeye gerek yoktur.
• Yorum satırları için // veya /// işaretlerini kullanın. /*…*/ işaretini kullanmaktan kaçının.
• Sadece gerekli olan yerlere yorum yazın. Bu sayede kodun okunabilirliği sağlanmış olur. Eğer metod ve değişken isimleri yeterince açıklayıcı şekilde seçilirse yorum satırlarına gerek kalmayacaktır.
• Kod yorum satırı olmadan da anlaşılabiliyorsa gereksiz yere yorum yazmayın. Yorum satırlarının dezavantajlarından biri de kod değiştirilip yorum satırı değiştirilmediğinde kafa karışıklığına yol açmasıdır.
• Az satırlı yorumlar kodu daha şık hale getirecektir. Ancak kod temiz, okunabilir değilse ve yorum satırları da yeterli değilse, bu durum da kötüdür.
• Mantıksal açıdan çok karmaşık bir kod varsa yani anlaşılması güç bir mantık kullanılmışsa kilit noktalarda açıklamalar yapmak uygun olacaktır.
• Yazım kurallarına uyan, noktalama işaretleri düzgün yorumlar yazın.

Hata Ayıklama

Serimizin son bölümünde hata yakalama ile ilgili bazı tekniklerden bahsedilmektedir.

• Bir cache exception tanımlayıp içini boş bırakmak doğru bir yöntem değildir. Çünkü bir hata oluştuğunda bize bir hata mesajı dönmeyecek ve hata yokmuş gibi kod işlemeye devam edecektir. Önemsiz hatalar için bu yöntemi uygulayan geliştiriciler vardır. Fakat siz programlı olarak her zaman hataları önlemek için çalışmalısınız. Hiç değilse hataları yakalayıp log dosyasına veya veritabanına kaydedip yola devam etmelisiniz.
• Hata oluştuğu durumlarda kullanıcıya uygun bir mesaj vermelisiniz. Fakat hatayı tüm detayları ile kayıt altına almalısınız.
• Her zaman genel Exception’lar yerine oluşabilecek hataya özgü Exception’lar yakalayın.

İyi Kod:

Kötü Kod:

• Tüm metodlarda hata yakalamaya gerek yoktur. Bazen uygulamanın çökmesi için açıklar bırakın. Bu sayede geliştirme aşamasında karşılaşılabiliecek hataları bulmanıza yardımcı olacaktır.
• Try-cache bloğunu tüm metodlarda kullanmayın. Başka bir şekilde önüne geçemeyeceğiniz hata durumları oluşacaksa kullanın. Örneğin veritabanına bir kayıt girerken kaydın zaten olup olmadığını anahtar değeriyle kontrol etmelisiniz. Bazen geliştirici kayıt sırasında kontrol etmeden giriş yapmaya çalışır ve hata durumunda kayıt zaten var zanneder. Bu kesinlikle kabul edilemez. Hata oluşmasını beklemeden önleminizi almalısınız.
• Gerektiği durumlarda kendi hata yakalama sınıflarınızı yazın. Özel sınıflarınızı SystemException sınıfından değil ApplicationException sınıfından türetin.

Alıntıdır:http://www.bayramucuncu.com/c-kod-standatlari-ve-en-iyi-programlama-teknikleri-bolum-1/