Dotnet Core HttpClient Kullanımı

29 Eki

Dotnet core veya .Net Framework uygulamalarında bir Web servisine erişmek için HttpClient sınıfından bir nesne oluşturulur ve kullanılır. Buraya kadar her şey normal. İşlem bittikten sonra kullanılan bu nesne yok edilir. İşte bu durumda işler biraz karışmaya başlar.

HttiClinet using blok ile kullanımı

public class ToDoClient : IToDoClient
{
	public async Task<Todo> Get(int id)
	{
		using(var client = new HttpClient())
		{
			BaseAddress = new Uri(
				"https://jsonplaceholder.typicode.com");
		}
		
		return await client.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

HttpClient sınıfı, IDisposible interface uyguladığı için, using bloğu ile kullanılabilir. Using bloğunda oluşturulan nesneler, blok sonunda ortadan kaldırılır. Ancak nesnenin kullandığı soket hemen serbest bırakılmaz. Ağır yük altında kullanılabilir soket sayısı azalır hatta tükenebilir. Burada konu ile ilgili bir yazı bulunmaktadır.

Yeniden kullanılabilir HttpClient nesnesi

Bu durumun önüne geçmek için tek bir kez singleton olarak oluşturulan ve paylaşılan bir HttpClient nesnesi kullanılabilir.

public class ToDoClient : IToDoClient
{
   private readonly HttpClient client = new ()
	{
		 BaseAddress = new Uri(
			"https://jsonplaceholder.typicode.com");
	};

	public async Task<Todo> Get(int id)
	{		
		return await client.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

Bu çözüm ise, az sayıda kullanılan kısa ömürlü console uygulamaları için uygun olabilir. Ancak geliştiricilerin karşılaştığı diğer bir sorun, uzun süren işlemlerde paylaşılan bir HttpClient örneği kullanırken ortaya çıkar. HttpClient’in tekil veya statik bir nesne olarak başlatıldığı bir durumda, DNS ip değişiklikleri yapılırsa uygulama hata alır. Örneğin load balancer ile bir DNS birden fazla ip de bulunan sunuculara sırayla yönlendiriliyor olabilir.

builder.Services.AddSingleton<IToDoClient, ToDoClient>();

Bu arada ToDoClient Program.cs içerisinde singleton olarak tanımlanabilir. Eğer Transient veya Scoped olarak kullanılırsa her request sırasında yeniden nesne oluşturacaktır. Bu durumun önüne geçmek için HttpCleint nesnesi static olarak tanımlanabilir.

public class ToDoClient : IToDoClient
{
    private static readonly HttpClient client = new ()
	{
		 BaseAddress = new Uri(
			"https://jsonplaceholder.typicode.com");
	};

	public async Task<Todo> Get(int id)
	{		
		return await client.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

Ancak bu durumda BaseAddress ile tanımlanan DNS TTL süresi bittiğinde domain adı yeni bir ip adresini işaret eder. Ancak kod restart olmadan yeni ip adresini bilemez. Çünkü default HttpClient içerisinde bunu yakalayan bir mekanizma bulunmaz. Bu durumun yakalayabilmek için SockeHttpHandler kullanılabilir.

public class ToDoClient : IToDoClient
{
	private SocketsHttpHandler socketHandler = new()
	{
		PooledConnectionLifetime = TimeSpan.FromMinutes(5)
	};
	
    private static readonly HttpClient client = new (socketHandler)
	{
		 BaseAddress = new Uri(
			"https://jsonplaceholder.typicode.com");
	};

	public async Task<Todo> Get(int id)
	{		
		return await client.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

Ancak bu yöntem de en iyi çözüm yolu değildir. En iyi çözüm yolu  .NET Core 2.1 ile birlikte gelen IHttpClientFactory interface kullanmaktır.

IHttpClientFactory Kullanımı

Bu interface kullanmadan önce Program.cs içerisinde bir tanımlama yapılması gerekmektedir.

builder.Services.AddSingleton<IToDoClient, ToDoClient>();
builder.Services.AddHttpClient<IToDoClient, ToDoClient>(client =>
{
   client.BaseAddress = new Uri(
			"https://jsonplaceholder.typicode.com");
});

Bu düzenleme ile artık HttpClient aşağıdaki gibi kullanılabilir.

public class ToDoClient : IToDoClient
{
    private readonly HttpClient _httpClient;
	
	public ToDoClient(HttpClient httpClient)
	{
		_httpClient = httpClient;
	}
	
	public async Task<Todo> Get(int id)
	{		
		return await _httpClient.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

Bu durumda HttpClient nesnesi IHttpClientFactory tarafından yönetilmektedir. Çünkü ortak bir havuzdaki HttpMessageHandler nesneleri, birden çok HttpClient örneği tarafından yeniden kullanılabilen nesnelerdir. Bu sayede DNS sorunu çözülmektedir.

Named Client kullanımı

Servis binding sırasında AddHttpClient() metoduna bir isim vererk kullanmak mümkündür.

builder.Services.AddSingleton<IToDoClient, ToDoClient>();
builder.Services.AddHttpClient("TodoApi",client =>
{
   client.BaseAddress = new Uri(
			"https://jsonplaceholder.typicode.com");
});
public class ToDoClient : IToDoClient
{
    private readonly IHttpClientFactory _httpClientFactory;
	
	public ToDoClient(IHttpClientFactory httpClientFactory)
	{
		_httpClientFactory = httpClientFactory;
	}
	
	public async Task<Todo> Get(int id)
	{		
	    var client = _httpClientFactory.CreateClient("ToDoApi");
		
		return await client.GetFromAsync<ToDo>(
			$"/todos/{id}");
	}
}

Bu sayede doğrudan IHttpClientFactory interface nesneleri ile HttpClient request’leri en verimli şekilde gerçekleştirilebilmektedir.

Kaynaklar

  • https://learn.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests
  • https://www.aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

Microsoft’un Çöpe Giden Yazılım Teknolojileri

25 Ara
  • Silverlight
  • WCF
  • WPF
  • Windows Forms
  • Web Forms

Microsoft teknolojilerinde son yıllarda önemli gelişmeler yaşanıyor. Takip etmekte zorlandığımız bu değişiklikler şüphesiz olması gereken şeylerdir. Yukarıda listelediğim teknolojiler, Microsoft’un  bir dönem parlayan yıldızlarıydı. Geçen zaman içinde yazılım dünyasında yaşanan evrim sonucu , Microsoft tarafında bir takım sorunlara çözüm bulmak ve bazı teknolojilerle rekabeti yakalayabilmek adına bir takım gelişmelere neden oldu. Yazılım dünyasındaki her yeni gelişme, karşımıza yeni bir ürün olarak çıktı. Gelişme ilerledikçe evrim, bir takım organların sonunu getirdi. Şunu da belirtmeliyim ki bu yazı Microsoft teknolojilerine karşı durmak için değil, bazı teknolojilerin zamanla yerini başka teknolojilere bıraktığını anlatmak amacıyla kaleme alınmıştır. Serbest pazar ortamında her firma ürününü ortaya koyar ve herkes istediği teknolojiyi dilediğince seçmekte özgürdür.

Silverlight

Adobe Flash, Java Flex v.b gibi client taraflı uygulamalara alternatif olarak üretilen zengin içerik ürünü Silverlight, mobil internet tarayıcılar tarafında yetersiz kalınca ve geliştiricilerin Javascript gibi tüm tarayıcılarda çalışabilen bir teknolojiyi tercih etmesiyle fişi çekilen teknolojilerden biri oldu. Ülkemizde ve diğer ülkelerde Silverlight düşkünü yazılımcılar için adeta bir hayal kırıklığı oldu. Çünkü bu gelişme birçok yatırımın güncelliğini yitirip zamanla çöpe gitmesi demekti.

WCF

Servis odaklı altyapı sistemleri için geliştirilen WCF teknolojisi SOAP ve RESTful servisler oluşturmak için bir altyapı sunmaktadır. HTTP tabanlı REST servislarinin yaygınlaşmasıyla ivme kaybeden ve durma noktasına gelen hatta bitti denilebilecek teknolojilerden birisi. WCF teknolojisi SOAP servisleri oluşturmak için ideal bir seçimdir. Ancak RESTful servisler oluşturma konusunda liderliğini WEB API teknolojisine kaptırmıştır. (Güncelleme: WCF servislerinin REST ve SOAP ayrımına vurgu yapıldı. 21.02.2015)

Windows Forms

Masaüstü programlama araçlarından Windows Forms teknolojisi ise WPF teknolojisinin gelmesiyle silikleşen teknolojiler arasında. WPF teknolojisini Windows Forms teknolojisine göre makul kılan özelliklerin başında View tarafı ile Model tarafının birbirinden ayrılmasını sağlamasıydı. Windows Froms, kod arayüzü ve grafik arayüzü ile çalışmaktadır. WPF ise kod arayüzü, grafik arayüzü ve grafik arayüzünü şekillendirebilen XAML arayüzü ile ortaya çıkmıştır. Bu durumda MVVM (Model-View-ViewModel) yazılım desenlerinin uygulanması kolaylaşmakta ve daha kolay yönetilebilir uygulamalar geliştirilebilmektedir.

WPF

Windows 8 ile birlikte bizi işletim sistemi düzeyinde şaşırtan Microsoft, XAML teknolojisini .Net framework tarafından işletim sistemi üzerine alarak bizi tekrar şaşırttı. Bu da demek oluyor ki artık masaüstünde artık WinRT teknolojisi yer alacak. Bu durumda WPF teknolojisi de yıkılmak üzere demektir.

Web Forms

Microsoft’un Web geliştirme tarafında sihirli çubuğu olan Web Forms teknolojisi de MVC uygulama mimarisine yenik düştmüştür diyebiliriz. Web Forms ile oluşturulmuş birçok popüler web sitesi bu günlerde MVC teknolojisine geçiş yapmaya başladı bile. Web Forms teknolojisinin hakkını yememek lazım ki çok sayıda popüler uygulamaya temel oluşturmuştur. Ancak MVC teknolojisinin iş birimlerinin birbirinden ayrılmasını sağlayan mimarisi ve bu sayede geliştirici hakimiyetini ön plana çıkarması ayrıca birim test yazmaya olanak  sağlaması zamanla onu popüler hale getirmiştir. Şahsen ben Web uygulamalarına direk MVC tarafından başlayanlardanım. (Güncelleme: 21.02.2015)

Microsoft gelişime, yeniliğe önem veren bir şirket. Ancak insanların yıllarca üzerinde çalışıp yatırım yaptığı teknolojilerin birden yok olması geliştiricileri ve şirket yöneticilerini sıkıntıya sokabiliyor. Bu durumda şu soru akıllara geliyor. Bu teknoloji de son bulursa ne yapacağız? Gelişim oldukça bir şeylerin sonu gelecek elbette.

Çöpe giden teknolojiler sadece Microsoft tarafıyla sınırlı değildir. Open source tarafında da çok fazla proje çöpe gitmiştir. Örneğin java tarafında da MVC yaygınlaşınca Serve taraflı bileşen teknolojiler pek tercih edilmez hale gelmiştir.

Bu durumda öngörülü olmak önem arz etmektedir. Spesifik teknolojiler yerine platform bağımsız teknolojilere eğilim göstermek her zaman faydalı olacaktır. Hangi programlama dili olursa olsun, yapılan iş genele hitap edecek şekilde tasarlanmalıdır. Bu sayede genişletilebilirlik(extensibility) ilkesi ile hareket etmiş oluruz ve hiç bir teknolojiye sıkı sıkıya bağımlı kalmayız.

Asp.net Globalization Ayarları

18 Tem

Asp.net projelerimizi yayınladığımızda bazen türkçe karakter sorunlarıyla karşılaşabilmekteyiz. Bu yazıda anlatmak istediğim Türkçe karakter sorununda ziyade geliştirme yaptığımız bilgisayarlar ile sunucular arasındaki kültür farkından kaynaklanabilecek sorunlar hakkında olacak.

Örneğin kendi makinamız türkçe işletim sistemli ve sunucumuz da yurt dışında. Bu durumda hem türkçe karakter sorunu, hem de tarihsel farklardan dolayı oluşabilecek tarih format farklılıkları gibi sorunlarla karşılaşabilmekteyiz. Bu durumu aşmak için yapmamız gereken web.config dosyası içerisindeki system.web alanına bir globalization ayarını düzenlemektir.


<system.web>
<globalization culture="tr-TR" />

Bu durumda kültük farkından kaynaklanan sorunlardan kurtulabilmekteyiz.

Eğer ASP.NET MVC projesi ile geliştirme yapıyorsak, Default model binder, kültür farkından dolayı tarih formatlarındaki property’leri set edemiyor. Böyle bir sorunu da bu şekilde aşabilmekteyiz.

Web Chart Aracı Visifire

13 Tem

Verilerin grafiksel gösterimi konusunda piyasada birçok araç mevcuttur. İşte bunlarda bir tanesi de Visfire Chart. Buradan aracı inceleyebilmek mümkün. Web ortamında online demolar sayesinde canlı görüntüleri izleyebiliyorsunuz.

Desteklenen platformlar :

  • Silverlight
  • SharePoint
  • WPF
  • Windows Phone

Özellikle silverlight ortamında çalışan chart tool bulmak biraz zordur. Bu açıdan visifire aracı ilgimi çekmiştir.

Dictionary Key Value değerlerinin birleştirlmesi

11 Tem

Dictionary tarzı, Key – Value çiftlerinden oluşmuş tiplerin elemanlarını birleştirerek göstermek istediğimiz durumlar oluşatuğunda ne yapmalıyız? Ben genelde bu tarz işlemlerde LINQ nimetlerinden faydalanmayı uygun buluyorum. Aksi taktirde diziler ve indexleriyle uğraşmak zorunda kalıyorum.

Web uygulamalarında URL oluştururken parametre değerlerini girmek istediğimizde, parametre adları ve değerlerini Key Value çiftleri olarak değerlendirebiliriz.

Örneğin şu şeklide bir URL oluturmak istiyoruz. www.bayramucuncu.com/urunler?id=5&categoryId=9&color=blue

Bu URL’in Querystring bölümünü (id=5&categoryId=9&color=blue) kısmını bu şekilde oluşturmaya çalışalım.

Öncelikle query string oluşturacak metodu yazmalıyız. Bu metodumuz da anahtar ve değer ikililerini tutan bir Dictionry<string,string> parametresi almalı.


private string queryString(Dictionary<string, string> parameters)
 {
      if (parameters == null)
          throw new ArgumentNullException("Parametreler boş gönderilemez");

      var pairs = parameters.Select(i => string.Format("{0}{1}{2}", i.Key, "=", i.Value));
      var values = string.Join("&", pairs);

      return string.Join("&", pairs);
 }

Bu şekilde, amaçladığımız query string  oluşturma işlemini yapacak metodu hazırladık. Şimdi de sonuca bakalım.

queryString(new Dictionary<string, string> { { “id”, “5” }, { “categoryId”, “9” }, { “color”, “blue” } });

şeklinde gönderilen bir dictionary sonucunda karşımıza şu şeklide bir resim çıkıyor.

ve işlem başarılı!

Tekrar görüşmek dileğiyle.

C# Kod Standatları ve En İyi Programlama Teknikleri Son– Bölüm 8

28 Kas
  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

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.

Bu yazı ile birlikte kod standartları serimizin sonuna gelmiş bulunuyoruz. Umarım faydalı bir yazı dizisi olmuştur. Herkere iyi çalışmalar.

C# Kod Standatları ve En İyi Programlama Teknikleri – Bölüm 7

26 Kas
  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

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.

C# Kod Standatları ve En İyi Programlama Teknikleri – Bölüm 6

14 Kas
  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

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.

C# Kod Standatları ve En İyi Programlama Teknikleri – Bölüm 5

13 Kas
  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

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.

C# Kod Standatları ve En İyi Programlama Teknikleri – Bölüm 4

9 Kas
  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

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 &lt; lines.Length; i++)
      {
        message += lines [i];
      }
      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 &lt; lines.Length; i++)
     {
        message.Append( lines[i] );
     }

     return message.ToString();
   }