10 Dakika veya Daha Az Sürede Visual Studio'da EditorConfig

Giriş: Neden EditorConfig Önemlidir

Tim, EditorConfig projesini tanıtarak başlıyor ve proje başına ayarların artık her zamankinden daha kolay uygulanabilir olduğunu açıklıyor. Visual Studio veya editör ayarları içinde saklanan kişisel tercihlere güvenmek yerine, artık tüm katkıcılar için tutarlı bir kodlama stili sürdürmek amacıyla bir projeyi yapılandırabilirsiniz.

Proje Oluşturma

EditorConfig dosyasını göstermek için Tim, Visual Studio'da yeni bir Blazor Server projesi oluşturur. BlazorDemoApp adını verir ve varsayılan yapılandırmayı kullanır. Bu basit .NET projesi, EditorConfig ayarlarını yapılandırmak ve uygulamak için bir test ortamı olarak hizmet eder.

Tim, bu projenin karmaşık bir mantık veya işlevsellik gerektirmediğini açıklar. Yalnızca kod stili kuralları ile çalışma için pratik bir örnektir.

Proje Tercihlerini ve Kodlama Stillerini Anlama

Burada Tim, proje düzeyinde yapılandırmanın neden önemli olduğunu tartışır. Visual Studio'da her kullanıcı aşağıdaki gibi tercihler belirleyebilir:

• Sekme mi yoksa boşluk mu kullanılacağı

• Girinti boyutu (örneğin, 3 veya 4 boşluk)

• Süslü parantezlerin {} aynı satıra mı yoksa yeni satıra mı yerleştirileceği

• Ad alanı deklarasyon türü (blok kapsamlı veya dosya kapsamlı)

Bu tercihler genellikle Visual Studio'da kullanıcı başına saklanır, proje başına değil. Tim, bir ekipte çalışırken herkesin yerel ayarlarının farklı olabileceğini vurgulamaktadır. Bu, tutarsız kod biçimlendirme, sürüm kontrol sistemlerinde gereksiz farklar ve tercihlerle elle hizalamaya harcanan zaman kaybı ile sonuçlanabilir.

Bu noktada EditorConfig dosya formatı yardımcı olur — tüm geliştirici editörlerinin otomatik olarak saygı gösterebileceği ortak bir EditorConfig özellik seti tanımlar.

EditorConfig Dosyası Oluşturma ve Açma

Tim daha sonra çözüme yeni bir EditorConfig dosyası nasıl ekleneceğini gösterir.

Çözüm üzerine sağ tıklayıp Ekle → Yeni EditorConfig seçeneğini seçer. Visual Studio, ilk kez dosyayı yüklediğinde küçük bir hata verebilir ancak Tim bunun zararsız bir tuhaflık olduğunu açıklar — sadece dosyayı kapatıp yeniden açın.

Bu yeni dosya genellikle .editorconfig olarak adlandırılır ve Visual Studio hemen onu bir yapılandırma belgesi olarak tanır. Visual Studio'nun, Visual Studio Code ve hatta Sublime Text gibi diğer metin editörleri tarafından metin editörü eklentileri yoluyla bu dosyayı yerel olarak desteklediği dikkate değerdir.

Tim, EditorConfig'in yalnızca Microsoft'a ait bir araç olmadığını açıklar. Farklı editörlerin aynı kodlama kurallarını anlamalarına ve uygulamalarına yardımcı olan sanayi çapında bir standarttır, birden çok ortamda tutarlı formatlamayı sağlar.

EditorConfig Dosya Ayarlarını Yapılandırma

EditorConfig dosyası açıldığında, Tim, mevcut Visual Studio yapılandırmasından varsayılan ayarları çektiğini açıklar. Ancak, gerektiğinde bunlar değiştirilebilir.

Boşluk bölümüne gider ve nasıl ayarlayacağını gösterir:

• Boşluklar yerine sekme kullanın

• Sekme genişliği = 3

Bunlar, kod biçimlendirmesinin nasıl davranması gerektiğini tanımlayan EditorConfig özelliklerine örneklerdir. Kaydedildikten sonra, bu yapılandırma tüm çözümde uygulanır, ancak dışında değil.

Tim, bu EditorConfig dosyasının da sürüm kontrol sistemlerine (Git gibi) eklenebileceğini, böylece depoyu klonlayan her geliştiricinin aynı kuralları devraldığından emin olunabileceğini not eder. Bu, kodu kimin yazdığına bakılmaksızın tutarlı formatlama sağlar.

Kod Stilleri ve Ad Alanı Kurallarıyla Çalışma

Daha sonra Tim, kod stili ayarlarına — özellikle ad alanı deklarasyon stiline dalar.

Varsayılan olarak, C# blok kapsamlı ad alanları kullanır, bu ad alanı süslü parantezlerle tanımlanır. Bu formatı göstermek için Data klasörü altında bir sınıf oluşturur.

Ardından, EditorConfig dosya ayarını dosya kapsamlı ad alanları kullanacak şekilde değiştirir. Başka bir sınıf eklediğinde, Visual Studio güncellenmiş stili otomatik olarak uygular — ad alanını süslü parantezler yerine noktalı virgül (;) ile gösterir.

Bu, EditorConfig ayarlarının Visual Studio'daki varsayılan kod üretimi şablonlarını nasıl etkileyebileceğini ve proje kurallarıyla otomatik olarak nasıl uyumlu hale gelebileceğini gösterir.

Tim ayrıca kod temizleme özelliğinin mevcut dosyaları yeniden biçimlendirmek için kullanılabileceğini, böylece tüm kodun en son EditorConfig kurallarına uygun kılınabileceğini belirtir.

Şiddet Seviyesini Ayarlamak ve Kuralları Uygulamak

Bu bölümde, Tim, EditorConfig dosyasındaki şiddet seviyeleri kullanarak kural uygulamayı nasıl kontrol edeceğine odaklanır.

Her kural none, suggestion, warning veya error gibi bir değerlere sahip olabilir. Tim, ad alanı kuralının şiddetini hata (error) olarak ayarlar ve hemen Visual Studio, tercih edilen formatla eşleşmeyen her dosyayı Hata Listesi penceresinde işaretler.

Bu, geliştiricilerin tanımlı stil kurallarını takip etmelerini sağlar ve mevcut dosyada veya tüm projede istenmeyen sapmaları önler.

Bazı tutarsızlıklar veya Visual Studio hata mesajları ortaya çıkabilir (yanlış öneri uyarıları gibi), ancak Tim bunların zaman içinde iyileşeceğini belirtiyor. Önemli olan, kuralların tutarlı bir şekilde uygulanmasıdır ve bu da kodun kolayca okunabilir ve tekdüze hale gelmesini sağlar.

Birden Fazla EditorConfig Dosyası ve Dizin Kapsamı

Tim, tek bir çözümde birden fazla EditorConfig dosyasına sahip olabileceğinizi açıklar.

Örneğin:

• Çözüm düzeyinde bir kök EditorConfig dosyası, tüm projeler için genel ayarlar tanımlar.

• /Data gibi bir alt klasördeki iç içe EditorConfig dosyası bazı özellikleri (örneğin, adlandırma kuralları, sekme genişliği veya satır araları) geçersiz kılabilir.

Her EditorConfig projesi hiyerarşik olarak davranır — yani alt dizinlerdeki dosyalar, üst dizinlerden devralır, aksi halde açıkça geçersiz kılınmadıkça.

Yapılandırmanızın kökünü tanımlamak istiyorsanız, en üst düzey dosyadaki kök özelliğini root = true olarak ayarlayabilirsiniz. Bu, editörlere, daha fazla EditorConfig dosyası aramak için üst dizinlerde aramayı durdurmalarını söyler.

Bu yapı, geliştiricilere proje düzeyinde biçimlendirme kuralları üzerinde ince ayar kontrolü sağlar, ancak farklı biçimlendirmenin mantıklı olabileceği özel durumları da sağlar.

Sonuç: EditorConfig ile Tutarlılık

Son yorumlarında, Tim geliştiricileri .NET projelerinde aktif olarak EditorConfig'i kullanmaya teşvik ediyor.

Bu yaklaşımın, ekiplerin tutarlı biçimlendirme kuralları, adlandırma konvansiyonları ve yerleşim stillerini sürdürmelerine olanak tanıdığını vurguluyor — herkesin kişisel düzenleyici ayarlarını değiştirmelerine zorlamadan. Açılan her dosya, projenin .editorconfig dosyasında belirlenen stilleri otomatik olarak izler.

Bu EditorConfig dosyalarını sürüm kontrol sistemlerine dahil ederek, ekipler herkesin — hangi editörü veya ortamı kullanırsa kullansın — aynı kod biçimlendirme kurallarına uymasını sağlar.

Tim, EditorConfig dosya formatının basit, esnek ve geniş şekilde desteklenen olduğunu vurgulayarak videosunu sonlandırıyor. Visual Studio, Visual Studio Code veya başka bir metin editörü kullanıyor olsanız da, bu, tutarlı kodlama stillerini sürdürmeye ve projenizi temiz, profesyonel ve okunabilir tutmaya yardımcı olmak için harika çalışır.