C # 'da kullanılmayan yönergeleri kullanarak neden kaldırılsın?

Geliştiricilerin UsingsVisual Studio 2008'de " Kullanılmayanları Kaldır " özelliğini kullanmasının herhangi bir nedeni olup olmadığını merak ediyorum (kaynak kodunu düzeltmenin dışında) ?

Onları çıkarmak istemeniz için birkaç neden var.

• Bu anlamsız. Hiçbir değer katmazlar.
• Kafa karıştırıcı. Bu ad alanından ne kullanılıyor?
• Bunu yapmazsanız using, kodunuz zamanla değiştikçe aşamalı olarak anlamsız ifadeler biriktireceksiniz .
• Statik analiz daha yavaştır.
• Kod derlemesi daha yavaştır.

Öte yandan, onları içeride bırakmak için pek fazla neden yok. Sanırım kendinizi onları silme zahmetinden kurtarıyorsunuz. Ama o kadar tembelsen, daha büyük sorunların var!

Tam tersini söyleyebilirim - gereksiz, gereksiz ifadeleri kaldırmak son derece yararlıdır.

Kodunuza 3, 6, 9 ay içinde geri dönmeniz gerektiğini veya başka birinin kodunuzu devralması ve bakımını yapması gerektiğini hayal edin.

Gerçekten ihtiyaç duyulmayan uzun bir ifade kullanma listeniz varsa, koda bakmak oldukça kafa karıştırıcı olabilir. Bu ad alanında hiçbir şey kullanılmıyorsa, neden orada kullanılıyor?

Sanırım profesyonel bir ortamda uzun vadeli sürdürülebilirlik açısından, kodunuzu olabildiğince temiz tutmanızı şiddetle öneririm - ve buna gereksiz şeylerin atılmasını da içerir. Daha az dağınıklık, daha az kafa karışıklığı ve dolayısıyla daha yüksek sürdürülebilirlik demektir.

üzüm posası

Bu bana çok mantıklı bir soru gibi görünüyor ve yanıt veren insanlar tarafından oldukça küstahça ele alınan bir soru.

Kaynak kodundaki herhangi bir değişikliğin gerekçelendirilmesi gerektiğini söyleyebilirim. Bu değişikliklerin gizli maliyetleri olabilir ve soruyu soran kişinin bundan haberdar edilmesini istedi. Bir kişinin tahmin ettiği gibi "tembel" olarak adlandırılmak istemediler.

Resharper'ı yeni kullanmaya başladım ve sorumlu olduğum proje hakkında uyarılar ve stil ipuçları vermeye başlıyor. Bunların arasında fazlalık kullanım yönergesinin kaldırılması, ancak aynı zamanda fazlalık niteleyiciler, büyük harf kullanımı ve daha pek çoğu yer alır. İçgüdülerim kodu düzeltmek ve tüm ipuçlarını çözmek, ancak iş başım beni haksız değişikliklere karşı uyarıyor.

Otomatikleştirilmiş bir derleme süreci kullanıyoruz ve bu nedenle SVN depomuzdaki herhangi bir değişiklik, projelere / hatalara / sorunlara bağlayamadığımız değişiklikleri oluşturacak ve önceki sürümlerde hiçbir işlevsel değişiklik sağlamayan otomatikleştirilmiş derlemeleri ve sürümleri tetikleyecektir.

Gereksiz niteleyicilerin kaldırılmasına bakarsak, bu, Etki Alanı ve Veri katmanlarımız yalnızca niteleyiciler tarafından ayırt edildiğinden, geliştiricilerde kafa karışıklığına neden olabilir.

Anakronimlerin (yani ABCD -> Abcd) büyük harf kullanımının doğru kullanımına bakarsam, o zaman Resharper'ın bu referans sınıf adlarını kullandığımız Xml dosyalarının hiçbirini yeniden düzenlemediğini dikkate almalıyım.

Dolayısıyla, bu ipuçlarını takip etmek göründüğü kadar basit değildir ve saygılı davranılmalıdır.

Önceden verilen nedenlere ek olarak, gereksiz adlandırma çatışmalarını önler. Bu dosyayı düşünün:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

Bu kod derlenmez çünkü hem System.IO hem de System.Windows.Shapes ad alanlarının her biri Path adında bir sınıf içerir. Tam sınıf yolunu kullanarak düzeltebiliriz,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

veya basitçe satırı kaldırabiliriz using System.Windows.Shapes;.

Intellisense açılır penceresindeki daha az seçenek (özellikle ad alanları çok sayıda Uzantı yöntemi içeriyorsa).

Teorik olarak Intellisense de daha hızlı olmalıdır.

Onları kaldır. Bakılacak ve merak edilecek daha az kod, zamandan ve kafa karışıklığından tasarruf sağlar. Keşke daha çok insan ŞEYLERİ BASİT, DÜZGÜN ve DÜZGÜN TUTAR. Odanızda kirli gömlek ve pantolon olması gibi. Bu çirkin ve neden orada olduğunu merak etmelisin.

Ayrıca, kullanılmayan kullanımları kaldırdıktan sonra projenizden bazı dll / proje referanslarını da kaldırabileceğinizi varsayarak, yanlış döngüsel bağımlılıkları önlemeye yardımcı olur.

Kod daha hızlı derlenir.

Son zamanlarda, kullanılmayan ithalatları silmenin oldukça yararlı ve önemli olmasının başka bir nedeni var.

Birinin diğerine başvurduğu iki derlemeniz olduğunu hayal edin (şimdilik ilkini Ave başvurulanı arayalım B). Şimdi A'da B'ye bağlı bir kodunuz olduğunda her şey yolunda. Bununla birlikte, geliştirme sürecinizin bir aşamasında, aslında artık bu koda ihtiyacınız olmadığını fark edersiniz, ancak using-ifadesini olduğu yerde bırakırsınız. Şimdi sadece anlamsız bir var using-directive değil, aynı zamanda bir montaj başvuru için Bherhangi bir yere kullanılmaz hangi ama eskimiş yönergede. Bu, öncelikle yüklenmesi gerektiği Agibi derleme için gereken süreyi artırır B.

Dolayısıyla bu, yalnızca daha temiz ve okunması daha kolay kodla ilgili bir sorun değil, aynı zamanda referans verilen tüm montajların bile mevcut olmadığı üretim kodundaki montaj referanslarının korunmasıyla ilgili bir sorun .

Son olarak bizim örneğimizde B ve A'yı birlikte göndermek zorunda kaldık, ancak B, A'da herhangi bir yerde değil- usingbölümünde kullanılır. Bu kitlesel etkileyecek çalışma zamanı içinde -Temsil Azaman yükleme düzeneği.

En azından teoride, size bir C # .cs dosyası (veya herhangi bir tek program kaynak kodu dosyası) verilmişse, koda bakabilmeli ve ihtiyaç duyduğu her şeyi simüle eden bir ortam yaratabilmelisiniz. Bazı derleme / ayrıştırma teknikleriyle, bunu otomatik olarak yapacak bir araç bile oluşturabilirsiniz. Bu, en azından sizin tarafınızdan yapılırsa, kod dosyasının söylediği her şeyi anladığınızdan emin olabilirsiniz.

Şimdi, usingyalnızca 10 tanesinin kullanıldığı 1000 yönergeli bir .cs dosyası verilip verilmediğini düşünün . Dış dünyaya atıfta bulunan kodda yeni eklenen bir sembole her baktığınızda, ne olduğunu anlamak için bu 1000 satırdan geçmeniz gerekecektir. Bu açıkça yukarıdaki prosedürü yavaşlatır. Yani onları 10'a indirebilirseniz, yardımcı olacaktır!

Kanımca, C # usingyönergesi çok zayıftır, çünkü genellik kaybolmadan tek bir genel sembolü belirtemezsiniz ve usinguzantı yöntemlerini kullanmak için takma ad yönergesini kullanamazsınız. Java, Python ve Haskell gibi diğer dillerde durum böyle değildir, bu dillerde dış dünyadan (neredeyse) tam olarak ne istediğinizi belirtebilirsiniz. Ama olay o usingzaman, mümkün olduğunda takma ad kullanmayı önereceğim .