Okunabilir XAML Yazmak

Any fool can write code that a computer can understand.  Good programmers write code that humans can understand. – Martin Fowler

Bahsettiğimiz konu kod yazmaya gelince bütün geliştiricilerin kendi standartları olabilir. Fakat yazdığımız kod ne olursa olsun biz bırakıp gittiğimizde kodumuzu okuyacak bir diğer insan bunu işkence görmeden başarabilmeli 🙂

Hangi dilde yazıyor olursak olalım eğer bir tasarım dili yazıyorsak visualization (görselleştirme) her zaman daha zor olacaktır. Çünkü yazdığımız şey aslında hayali bir çerçeve içerisinde hayali şeylerin nasıl görüneceğini belirlemek. Yazdığımız kodların bu hayali çerçeve içerisinde nasıl görüneceğini zaman içerisinde biz de kestirebiliyoruz. Fakat bu büyük bir uğraş ve zaman gerektiriyor. Yeni XAML yazmaya başlamış birinin Designer kullanmadan tasarım yapması beklenemez. Gün geçtikçe Designerdan uzaklaşıp XAML’ı kod tarafında yazmak hem geliştiricinin yazdığı kodu görselleştirmesinde hem de daha hızlı geliştirme yapmasına yardımcı olacaktır.

Daha önce de söylediğim gibi bütün geliştiricilerin kendilerine has standartları olabilir. En basitinden Camel & Pascal Case diye ayırdığımız naming conventionları örnek verebiliriz. Peki iş tamamen görsele dayalı bir dil olduğunda okunabilirliği nasıl sağlayabiliriz?

Bu yazıda kendi günlük geliştirmelerimde yaptığım XAML sayfalarında dikkat etmeye çalıştığım ve kod okunabilirliğini arttırmaya yardımcı olacak maddeleri sıraladım. Bunlar benim standartlarım olduğu için herhangi bir geçerliliği elbet yok. Fakat yazının amacı eğer okunabilirliği arttırmaksa aşağıdaki maddeler hem size hem de sizden sonraki geliştiricilere hayatı büyük bir oranda kolaylaştıracağından eminim.

Ortak özelliklere sahip elementler için Style kullanın.

Copy – paste programming günümüzde bu kadar yaygınlaşmışken sayfa veya proje içerisinde aynı özelliklere sahip elementler için kullanmanız gereken Style kodlarının da bu kadar az olması haliyle kaçınılmaz. Çoğu geliştirici için bir tane elementi tam haliyle yazıp onu kopyalayıp yapıştırarak çoğaltmak, bu elementlerin kullanabileceği ortak bir Style kodu yazmakdan daha kolay geliyor. Şimdi bunu yapmanın işinizi ne kadar kolaylaştırdığı tartışılabilir. Fakat kopyala – yapıştır yaparak çoğalttığınız elementlerin büyük çaplı projelerde başınıza dert olacağı bir kaçınılmazdır.

Style kodları kullanmak yönetmesi kolay bir tasarım kodu oluşturmaya yardımcı olur. Ayrıca her maddede olduğu gibi kod anlaşılabilirliğini had safhada tutmanızı sağlar. Resimlerle örneklemek gerekirse:

Birbirlerinden bağımsız fakat aynı özelliklere sahip TextBlocklar.

Birbirlerinden bağımsız fakat aynı özelliklere sahip TextBlocklar.

Page Resource içerisine tanımlanmış bir Style koduyla tanımlanmış TextBlocklar.

Page Resource içerisine tanımlanmış bir Style koduyla tanımlanmış TextBlocklar.

 

 

Birbirine benzer fakat çok az propertyler ile birbirinden ayrılan stil parçaları için BasedOn kullanarak ana stilden farklı stil parçaları oluşturabilirsiniz.

Sayfa içerisindeki bütün TextBlocklar aynı stile sahip olacaksa bir x:Key tanımlaması yapmanıza gerek yok. Ayrıca her zaman olduğu gibi gerektiği yerlerde comment tagleri içerisine açıklama yazmayı öncelik sıranıza almayı unutmayın.

UI Elementleri yazarken belirlediğiniz kurallara uyun.

Şimdi bu da aslında yazıda yazdığım bütün maddeler gibi size kalmış bir şey. Fakat code-readability (kod okunabilirliği) açısından en önemli unsurlardan biri. Geliştirdiğiniz projelerin her aşamasında olduğu gibi yazdığınız kodun başkası tarafından rahatça okunabilinip anlaşılabiliyor olması beklenir. İş tasarım dili olunca da backend kodu gibi şöyle bir göz gezdirilip devam edilemeyebiliyor çoğu zaman. Çünkü bir componentin tanımlanmış 10’dan fazla propertysi olabilir. Bunların hepsini bir XAML koduna bakıp akılda tutmak ya da yeri geldiğinde dönüp bulmak vakit kaybına yol açabilir. İşte bu tarz ufak gibi görünen ama aslında geliştirme zamanınızı çok daha hızlandırabilecek küçük unsurları düzeltmek için şunları yapabilirsiniz:

Inline yerine Newline kullanın

Aşağıya iki farklı resim ile çok propertyli bir UI element kodu ekliyorum, sanırım bahsettiğim şeyi anlayacaksınız.

Inline

Inline

Newline

Newline

 

 

 

 

 

 

Sonuç olarak iki resimdeki kod da aynı işi yapıyor ve aynı elementi ekrana basıyor. Fakat alt resimeki koda baktığımızda okunabilirlik diğerine göre daha çok daha fazla.

Kendi rulesetinizi oluşturun

Şimdi Ruleset dediğimiz olay aslında kod kalitesini arttırmak ve kod okunabilirliğini yüksek seviyelerde tutmak için geliştirilmiş bir dosyadan başka bir şey değil. Visual Studio içerisinde belirli rulelara (kurallara) göre kod yazmak da aslında bu bahsettiğim iki unsuru destekleyen bir unsur. Daha detaylı bilgi için şu MSDN sayfasını inceleyebilirsiniz.

Benim bahsettiğim ruleset ise tamamen sizin kendi kod standartınıza uygun bir hayali ruleset. Emin olmamakla beraber bildiğim kadarıyla şu an Rule dosyaları XAML içerisinde kullanılamıyor. Bu durumda da bize düşen kendi hayali rulesetimizi oluşturup kodu ona göre yazmak. Nasıl mı?

Örneğin XAML dosyası içerisine tanımladığımız her bir componente erişmek için bir x:Name tanımlar ve onu kullanırız. Ben şahsen bunu her zaman componentin ilk propertysi olarak hemen altına tanımlamaya özen gösteririm. Bu gerekli bir şey değil, isterseniz ortalarda bir yere ya da en görünmeyen yere yazın hiç fark etmez, sonuçta compilerdan geçtiğinde pek bir önemi kalmıyor, değil mi? 🙂 Değil abi. Özellikle designer çok exceptional caseler dışında designer kullanmayan biri olarak bu benim için önemli. Benim için aslında uymaya çalıştığım ruleset öncelik sırasına göre şöyle:

  1. x:Name her zaman en başta olmalı ki ben neyle uğraştığımı anlamak için gözümü ordan oraya çevirmeyeyim.
  2. Eğer kontrol bir Grid içerisinde ise attached propertyleri olan Row ve Column propertyleri her zaman ikinci sırada, x:Name’den sonra gelir. Bunun nedeni de Grid yapısını kullanırken elementin tam olarak nerede render edileceğini kafamda daha rahat canlandırabilmem aslında.
  3. Width ve Height propertyleri olabildiği en üst sıralara yazılır. Bunun sebebi de yine Row ve Column ile aynı aslında. Tamamen yazılan tasarım kodunu kafamda rahat canlandırabilmek.
  4. Bunlardan sonra gelen propertyler öncelik sırasına göre yazılır.

Bunlar benim uymaya çalıştığım kurallar. Siz de yukarıdakiler gibi kendi kurallarınızı oluşturup bunları projenin uygun bir yerine açıklayıcı bir şekilde yazabilirsiniz. Böylece bir dahaki sefere neyi nerde bulabileceğinizi daha kolay bir şekilde halledebilirsiniz. Aşağıda yine kıyaslama adına iki farklı resim paylaşıyorum.

Yapılması gereken.

Yapılması gereken.

Koşarak uzaklaşılması gereken.

Koşarak uzaklaşılması gereken.

 

 

 

 

 

 

 

Yukarıdaki Grid içerisinde Row setter indexi 0 olan Textblock için atama yapılması tercih sebebidir.

Bütün Resourceları tek bir yere yazmayın.

Hepimizin nimetlerini sonuna kadar kullandığı bir dosya var. App.xaml 🙂 İş resource yönetimine gelince çoğu zaman her şeyi en kolay yöntem olan App.xaml üzerine yüklüyoruz. Bu da geniş çaplı projelerde gereksiz resourceların tek bir dosyada toplanmasını beraberinde getiriyor. Bu durum her ne kadar günümüz bilgisayarlarının halledemeyeceği kadar yoğun bir iş yükü oluşturmuyor olsa da amacımız her şeyi nizami bir şekilde geliştirmek. Peki nedir bunun yolu / yordamı?

ResourceDictionary kullanın

ResourceDictionary ile farklı amaçlar için saklamak istediğiniz farklı türdeki resourceları (örneğin Converter’lar, DataTemplate’ler, Style’lar) farklı xaml dosyaları içerisine yazarak tek bir yerde toplayabilirsiniz.

Ayrıştırılmış Resource dosyaları.

Ayrıştırılmış Resource dosyaları.

 

 

 

 

 

Tek bir dosya için kullanacağınız resourceları ortak alanlara yazmaktan kaçının

Yalnızca tek bir sayfa için kullanacağınız bir DataTemplate’i App.xaml veya farklı bir Resource xaml’ı içerisinde yazmanın hiç bir anlamı yok. Eğer yazdığınız bu template yalnızca o sayfa içerisinde kullanılacaksa Page.Resources altına yazabilirsiniz. Bu ayrıca IntelliSense’in gerektiği durumlarda kod bölüğünü bulmasını da hızlandıracaktır.

Yüksek Margin ve Padding değerleri kullanmayın.

WinRT, UWP, WPF vs. konusunda yeni yeni geliştirme yapmaya başlamış bir geliştiricinin en çok düştüğü hatalardan biri Designer üzerinden ekrana sürükleyip bıraktığı kontrolün, uygulamanın çalıştığı ekran çözünürlüğü ne olursa olsun hep aynı yerde gözükeceğidir. Bu tabiki de yanlıştır, çünkü siz drag & drop yöntemiyle ekranın herhangi bir yerine bir element sürüklediğiniz zaman Designer bu elemente sizin koyduğunuz yere uygun olması için gerekli Margin değerlerini otomatik olarak atar. Görünürde bir saçmalık yoktur, çünkü zaten XAML Designer bunu sizin görmek istediğiniz şekilde ayarladı bile. Sorun bu uygulamayı farklı çözünürlüklerde çalıştırdığınız zaman ortaya çıkar.

Margin ve Padding propertyleri için okunabilirliği ele almamız yine bize visualization (canlandırma) konusunda yardımcı olabilir. Küçük değerlerle çalışmak hem bu canlandırmayı kolaylaştırdığı gibi hem de farklı çözünürlüklerde uçuk kaçık elementler görmemizi engeller. Yani aslında küçük değerlerle çalışıp istediğimiz ekran görüntüsünü yakalayabilmek bizim veya çalışma arkadaşlarımızın işini okunabilirlik konusunda kolaylaştırdığı gibi farklı ekran çözünürlüklerinde test ettiğimiz elementlerin çok farklı yerlerde konumlanmasını engeller.

 

0
Shares