10 Dakikada veya Daha Az Sürede Visual Studio'da EditorConfig
[[academy-video-youtube({"vid": "CQW5b58mPdg", "start_time": "0", "title": "10 Dakikada veya Daha Az Sürede Visual Studio'da Editorconfig", "creator": "Tim Corey", "length": "9m 28s"})]]
Çeşitli proje ve geliştiriciler arasında tutarlı kodlama stillerini sürdürmek, özellikle farklı kurulumlar, tercihler veya hatta Visual Studio ve Visual Studio Code gibi farklı düzenleyiciler kullanan takımlarla çalışırken zorlayıcı olabilir. Tim Corey, "EditorConfig in Visual Studio in 10 Minutes or Less" videosunda EditorConfig dosyasının .NET projelerinde proje özelinde kodlama kurallarını tanımlamayı ve zorlamayı nasıl mümkün kıldığını açıklar.
Bu makale, Tim'in açıkladığı kavramları tam olarak göstererek, EditorConfig C# ayarlarının kod stili, girintileme ve yapıdaki tutarlılığı nasıl koruduğunu gösterir. Tim'in açıklamalarını adım adım inceleyelim.
Giriş: Neden EditorConfig Önemlidir
Tim, EditorConfig projesini tanıtarak, proje başına ayarların şimdi her zamankinden daha kolay uygulandığını açıklayarak başlar. Visual Studio içinde kaydedilen kişisel tercihlere veya düzenleyici ayarlarına güvenmek yerine, artık tüm katkıda bulunanlar için tutarlı bir kodlama stilini korumak için bir proje yapılandırabilirsiniz.
Projeyi 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 konfigürasyonu kullanır. Bu basit .NET projesi, EditorConfig ayarlarını belirlemek ve uygulamak için bir test alanı olarak hizmet eder.
Tim'in açıkladığı gibi, bu projenin karmaşık mantık veya işlevselliğe ihtiyacı yoktur. Sadece kod stil kuralları üzerinde çalışmak için uygun bir örnektir.
Proje Tercihlerini ve Kodlama Stillerini Anlamak
Burada Tim proje düzeyinde yapılandırmanın neden önemli olduğunu tartışır. Visual Studio'da, her kullanıcı şu gibi şeyler için tercihler ayarlayabilir:
Sekme mi yoksa boşluk mu kullanılacağı
Girintileme boyutu (ör: 3 veya 4 boşluk)
Kıvırcık parantezlerin aynı satırda veya yeni satırlarda yerleştirilmesi
- Ad alanı bildirimi türü (block-scoped veya file-scoped)
Bu tercihler genellikle projesiz Visual Studio kullanıcı başına depolanır. Tim, bir takımda çalışırken herkesin yerel ayarlarının farklı olabileceğine dikkat çeker. Bu, tutarsız kod biçimlendirmesine, sürüm kontrol sistemlerinde gereksiz farklara ve tercihlerin manuel olarak hizalanması için kaybedilen zamana neden olabilir.
EditorConfig dosya formatı işte burada yardımcı olur — tüm geliştiricilerin düzenleyicilerinin otomatik olarak saygı gösterebileceği paylaşılan bir EditorConfig özellikleri setini tanımlar.
EditorConfig Dosyasını Oluşturma ve Açma
Tim, çözüme yeni bir EditorConfig dosyası eklemeyi nasıl göstereceğini devam eder.
Çözüm üzerinde sağ tıklayıp Ekle → Yeni EditorConfig'i seçer. Visual Studio ilk kez dosyayı yüklediğinde küçük bir hataya neden olabilir, ancak Tim bunun zararsız bir gariplik olduğunu açıklar — sadece dosyayı kapatın ve yeniden açın.
Bu yeni dosya genellikle .editorconfig adını alır ve Visual Studio hemen bunu bir yapılandırma belgesi olarak tanır. Visual Studio'nun bu dosyayı yerel olarak desteklediği ve Visual Studio Code ve Sublime Text gibi diğer metin düzenleyicilerin de metin düzenleyici eklentileri aracılığıyla desteklediği kayda değerdir.
Tim, EditorConfig'in yalnızca bir Microsoft aracı olmadığını açıklar. Bu, farklı düzenleyicilerin aynı kodlama kurallarını anlamasına ve uygulamasına yardımcı olan ve çoklu ortamlar arasında tutarlı biçimlendirme sağlayan endüstri çapında bir standarttır.
EditorConfig Dosya Ayarlarını Yapılandırma
EditorConfig dosyası açıldığında, Tim bunun mevcut Visual Studio yapılandırmasından varsayılan ayarları çektiğini açıklar. Ancak, gerektiği gibi bunlar değiştirilabilir.
Boşluklar bölümüne gider, nasıl ayarlanacağını gösterir:
Boşluklar yerine sekme kullan
- Sekme genişliği = 3
Bunlar, kod biçimlendirmesinin nasıl davranacağını tanımlayan EditorConfig özellikleri örnekleridir. Bir kez kaydedildikten sonra, bu yapılandırma tüm çözüm boyunca uygulanır, ancak dışarıda değil.
Tim, bu EditorConfig dosyasının da sürüm kontrol sistemlerine (Git gibi) eklenebileceğini ve her geliştiricinin havuzu klonladığında aynı kuralları devralmasını sağlar. Kim yazarsa yazsın tutarlı biçimlendirmeyi korumaya yardımcı olur.
Kod Stilleri ve Ad Alanı Kuralları İle Çalışma
Tim daha sonra kod stil ayarlarına girer—özellikle ad alanı bildirim stiline.
Varsayılan olarak, C# kıvırcık parantezlerle tanımlanan block-scoped ad alanlarını kullanır. Bu formatı göstermek için Data klasörünün altında bir sınıf oluşturur.
Ardından, EditorConfig dosya ayarını file-scoped ad alanlarını kullanmak için değiştirir. Başka bir sınıf eklediğinde, Visual Studio güncellenmiş stili otomatik olarak uygular — ad alanını parantez yerine noktalı virgül (;) ile gösterir.
Bu, EditorConfig ayarlarının Visual Studio'da varsayılan kod oluşturma şablonlarını nasıl etkilediğini gösterir ve tanımlanan proje kurallarıyla otomatik olarak hizalanır.
Tim ayrıca, tüm kodun en son EditorConfig kurallarına uygun olduğundan emin olmak için mevcut dosyaların yeniden biçimlendirilmesi amacıyla kod temizleme özelliğinin kullanılabileceğine işaret eder.
Şiddet Seviyesini Ayarlama ve Kuralları Uygulama
Bu bölümde Tim, EditorConfig dosyasında şiddet seviyelerini kullanarak kural uygulamayı nasıl kontrol edebileceğini odaklanır.
Her kural, none, suggestion, warning veya error gibi bir değere sahip olabilir. Tim, ad alanı kuralının şiddetini error olarak ayarlar ve hemen Visual Studio, tercih edilen formatla eşleşmeyen herhangi bir dosyayı Hata Listesi penceresinde işaretler.
Bu, geliştiricilerin tanımlanmış tarzlara uymalarını sağlar ve istenmeyen sapmaları mevcut dosyada veya tüm projede önler.
tekdüze hale gelmesini sağlar
Birden Fazla EditorConfig Dosyası ve Dizini Kapsamı
Tim, tek bir çözümde birden fazla EditorConfig dosyası kullanabileceğinizi açıklar.
Örneğin:
- Çözüm düzeyinde bir kök EditorConfig dosyası tüm projeler için genel ayarları tanımlar.
Alt klasörde /Data gibi bir iç içe geçmiş EditorConfig dosyası, bazı özellikleri (örn., adlandırma kuralları, sekme genişliği veya satır sonları) geçersiz kılabilir.
Her EditorConfig projesi hiyerarşik olarak çalışır — bu, alt dizinlerdeki dosyaların, açıkça geçersiz kılınmadıkça, üst dizinlerden miras aldıkları anlamına gelir.
Konfigürasyonunuzun kökünü tanımlamak istiyorsanız, en üst düzey dosyada root = true özelliğini ayarlayabilirsiniz. Bu, editörlere başka EditorConfig dosyalarını aramayı durdurmalarını söyler.
Bu yapı, geliştiricilere proje düzeyindeki biçimlendirme kuralları üzerinde ayrıntılı kontrol sağlar, aynı zamanda farklı biçimlendirmenin mantıklı olabileceği özel durumlara da izin verir.
Sonuç: EditorConfig ile Tutarlılık
Son sözlerinde Tim, geliştiricileri .NET projelerinde EditorConfig'i aktif bir şekilde kullanmaya teşvik ediyor.
Bu yaklaşımın, ekiplerin tutarlı biçimlendirme kuralları, adlandırma standartları ve düzen stillerini koruyabilmesini sağladığını, bunların kişisel editör ayarlarına değişiklik yapmadan yapılabileceğini vurguluyor. Her açılan dosya, projenin .editorconfig dosyasında tanımlanan stilleri otomatik olarak takip eder.
Bu EditorConfig dosyalarını sürüm kontrol sistemlerine ekleyerek, ekipler herkesin — editör veya ortam fark etmeksizin — aynı kod formatlama kurallarına uymasını sağlar.
Tim, videosunu EditorConfig dosya formatının basit, esnek ve geniş çapta desteklendiğini vurgulayarak sonlandırıyor. İster Visual Studio, ister Visual Studio Code veya başka bir metin düzenleyici kullanıyor olun, tutarlı kodlama stillerini korumaya ve projenizi temiz, profesyonel ve okunabilir tutmaya yardımcı olacak şekilde çalışır.

