Tại sao loại bỏ các chỉ thị sử dụng không sử dụng trong C #?

Tôi tự hỏi liệu có bất kỳ lý do nào (ngoài việc thu dọn mã nguồn) tại sao các nhà phát triển sử dụng tính năng "Loại bỏ không sử dụng Usings" trong Visual Studio 2008 không?

Có một số lý do bạn muốn loại bỏ chúng.

• Nó là vô nghĩa. Chúng không có giá trị gì.
• Thật khó hiểu. Điều gì đang được sử dụng từ không gian tên đó?
• Nếu không, bạn sẽ dần dần tích lũy các usingcâu lệnh vô nghĩa khi mã của bạn thay đổi theo thời gian.
• Phân tích tĩnh chậm hơn.
• Quá trình biên dịch mã chậm hơn.

Mặt khác, không có nhiều lý do để xóa chúng. Tôi cho rằng bạn tiết kiệm cho mình công sức xóa chúng. Nhưng nếu bạn lười biếng như vậy, bạn sẽ gặp vấn đề lớn hơn!

Tôi sẽ nói hoàn toàn ngược lại - việc loại bỏ các câu lệnh sử dụng không cần thiết, không cần thiết là vô cùng hữu ích.

Hãy tưởng tượng bạn phải quay lại mã của mình sau 3, 6, 9 tháng - hoặc người khác phải tiếp quản và duy trì mã của bạn.

Nếu bạn có một danh sách dài khổng lồ về câu lệnh sử dụng không thực sự cần thiết, thì việc nhìn vào mã có thể khá khó hiểu. Tại sao điều đó được sử dụng trong đó, nếu không có gì được sử dụng từ không gian tên đó ??

Tôi đoán về khả năng bảo trì lâu dài trong một môi trường chuyên nghiệp, tôi thực sự khuyên bạn nên giữ cho mã của bạn sạch nhất có thể - và điều đó bao gồm cả việc loại bỏ những thứ không cần thiết khỏi nó. Ít lộn xộn hơn đồng nghĩa với ít nhầm lẫn hơn và do đó khả năng bảo trì cao hơn.

Marc

Đối với tôi, đây có vẻ là một câu hỏi rất hợp lý, được những người trả lời đối xử một cách khá phiến diện.

Tôi muốn nói rằng bất kỳ thay đổi nào đối với mã nguồn cần phải được xác minh. Những thay đổi này có thể có chi phí ẩn và người đặt câu hỏi muốn được biết về điều này. Họ không yêu cầu được gọi là "lười biếng", như một người đã thống nhất.

Tôi vừa mới bắt đầu sử dụng Resharper và nó đang bắt đầu đưa ra các cảnh báo và gợi ý về phong cách cho dự án mà tôi chịu trách nhiệm. Trong số đó là việc loại bỏ chỉ thị sử dụng thừa, ngoài ra còn có các định tính thừa, viết hoa và nhiều thứ khác. Bản năng ruột của tôi là làm gọn mã và giải quyết tất cả các gợi ý, nhưng người đứng đầu doanh nghiệp của tôi cảnh báo tôi trước những thay đổi không chính đáng.

Chúng tôi sử dụng quy trình xây dựng tự động và do đó bất kỳ thay đổi nào đối với kho lưu trữ SVN của chúng tôi sẽ tạo ra các thay đổi mà chúng tôi không thể liên kết với các dự án / lỗi / sự cố và sẽ kích hoạt các bản dựng và bản phát hành tự động không mang lại thay đổi chức năng cho các phiên bản trước.

Nếu chúng ta xem xét việc loại bỏ các vòng loại dư thừa, điều này có thể gây ra nhầm lẫn cho các nhà phát triển vì các lớp Miền và lớp Dữ liệu của chúng tôi chỉ được phân biệt bởi các vòng loại.

Nếu tôi xem xét việc sử dụng thích hợp cách viết hoa của các từ đồng nghĩa (tức là ABCD -> Abcd) thì tôi phải tính đến việc Resharper không cấu trúc lại bất kỳ tệp Xml nào mà chúng tôi sử dụng tên lớp tham chiếu đó.

Vì vậy, việc làm theo những gợi ý này không hề đơn giản như nó xuất hiện, và cần được đối xử một cách tôn trọng.

Ngoài những lý do đã được đưa ra, nó ngăn chặn các xung đột đặt tên không cần thiết. Hãy xem xét tệp này:

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

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

Mã này không biên dịch vì cả hai không gian tên System.IO và System.Windows.Shapes đều chứa một lớp được gọi là Đường dẫn. Chúng tôi có thể sửa nó bằng cách sử dụng đường dẫn lớp đầy đủ,

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

hoặc chúng tôi có thể chỉ cần xóa dòng using System.Windows.Shapes;.

Ít tùy chọn hơn trong cửa sổ bật lên Intellisense (đặc biệt nếu không gian tên chứa nhiều phương thức Mở rộng).

Về mặt lý thuyết, Intellisense cũng sẽ nhanh hơn.

Loại bỏ chúng. Ít mã để xem và băn khoăn về tiết kiệm thời gian và sự nhầm lẫn. Tôi ước nhiều người hơn sẽ GIỮ ĐƯỢC NHỮNG ĐIỀU ĐƠN GIẢN, NHANH CHÓNG và THẬT SỰ. Nó giống như có áo sơ mi và quần bẩn trong phòng của bạn. Nó xấu xí và bạn phải tự hỏi tại sao nó ở đó.

Nó cũng giúp ngăn chặn sự phụ thuộc vòng tròn sai, giả sử bạn cũng có thể xóa một số tham chiếu dll / dự án khỏi dự án của mình sau khi loại bỏ các phần không sử dụng.

Mã biên dịch nhanh hơn.

Gần đây, tôi có một lý do khác tại sao việc xóa các mục nhập không sử dụng lại khá hữu ích và quan trọng.

Hãy tưởng tượng bạn có hai tập hợp, trong đó một tập hợp tham chiếu đến tập hợp kia (bây giờ chúng ta hãy gọi cái đầu tiên Avà cái được tham chiếu B). Bây giờ khi bạn có mã ở A phụ thuộc vào B thì mọi thứ đều ổn. Tuy nhiên ở một số giai đoạn trong quá trình phát triển của bạn, bạn nhận thấy rằng bạn thực sự không cần mã đó nữa nhưng bạn để nguyên câu lệnh using. Bây giờ bạn không chỉ có using-directive vô nghĩa mà còn có một assembly-tham chiếu đến Bmà không được sử dụng ở bất kỳ đâu ngoài chỉ thị đã lỗi thời. Điều này trước hết làm tăng lượng thời gian cần thiết để biên dịch A, nhưB cũng phải tải.

Vì vậy, đây không chỉ là vấn đề về mã sạch hơn và dễ đọc hơn mà còn về việc duy trì tham chiếu lắp ráp trong mã sản xuất, nơi không phải tất cả các tập hợp tham chiếu đó đều tồn tại .

Cuối cùng, chúng tôi phải gửi B và A cùng nhau, mặc dù B không được sử dụng ở bất kỳ đâu trong A mà trong using-section. Điều này sẽ ảnh hưởng lớn đến thời gian chạy -performance của Akhi tải lắp ráp.

Ít nhất về lý thuyết, nếu bạn được cung cấp tệp C # .cs (hoặc bất kỳ tệp mã nguồn chương trình đơn lẻ nào), bạn sẽ có thể xem mã và tạo môi trường mô phỏng mọi thứ mà nó cần. Với một số kỹ thuật biên dịch / phân tích cú pháp, bạn thậm chí có thể tạo một công cụ để làm điều đó tự động. Nếu điều này ít nhất do bạn thực hiện, bạn có thể đảm bảo rằng bạn hiểu mọi thứ mà tệp mã nói.

Bây giờ, hãy xem xét, nếu bạn được cung cấp tệp .cs có 1000 using chỉ thị mà chỉ có 10 chỉ thị thực sự được sử dụng. Bất cứ khi nào bạn nhìn vào một biểu tượng mới được giới thiệu trong mã liên quan đến thế giới bên ngoài, bạn sẽ phải trải qua 1000 dòng đó để tìm ra nó là gì. Điều này rõ ràng là làm chậm quá trình trên. Vì vậy, nếu bạn có thể giảm chúng xuống 10, nó sẽ hữu ích!

Theo ý kiến ​​của tôi, usingchỉ thị C # rất yếu, vì bạn không thể chỉ định ký hiệu chung duy nhất mà tính chung chung bị mất và bạn không thể sử dụng usingchỉ thị bí danh để sử dụng các phương thức mở rộng. Đây không phải là trường hợp của các ngôn ngữ khác như Java, Python và Haskell, trong các ngôn ngữ đó, bạn có thể chỉ định (gần như) chính xác những gì bạn muốn từ thế giới bên ngoài. Nhưng nếu có, tôi sẽ đề nghị sử dụng usingbí danh bất cứ khi nào có thể.