2009-01-09 35 views
29

Tôi hiện đang sử dụng bản dùng thử 30 ngày của ReSharper và cho đến nay tôi đã rất ấn tượng với những đề xuất mà nó đưa ra. Tuy nhiên, một gợi ý gợi nhớ tôi.Từ khóa C# 'var' so với các biến được xác định rõ ràng

Khi tôi xác định một cách rõ ràng một biến, chẳng hạn như:

List<String> lstString = new List<String>(); 

ReSharped thêm một chút dòng nguệch ngoạc màu xanh lá cây và bảo tôi:

Sử dụng ngầm gõ khai báo biến cục bộ.

Nếu tôi sau đó làm theo gợi ý của nó, ReSharper thay đổi dòng mã để:

var lstString = new List<String>(); 

Vì vậy, có một số loại đạt được hiệu suất để có được từ việc thay đổi List<String> đến một var, hoặc là điều này chỉ đơn thuần là một đặc thù của ReSharper? Tôi đã luôn luôn được dạy rằng xác định rõ ràng một biến, thay vì sử dụng một năng động, là tối ưu hơn.

+0

var khác với từ khoá động, cũng trình biên dịch sẽ chuyển đổi từ khóa var để thực tế loại xử lý – erdogany

Trả lời

60

Vì vậy, có một số loại đạt được hiệu suất để có được từ việc thay đổi danh sách vào một var

Không, nhưng đây không phải là lý do hợp lệ duy nhất để tái cấu trúc. Quan trọng hơn, nó loại bỏ sự dư thừa và làm cho mã ngắn hơn mà không mất đi sự rõ ràng nào.

Tôi luôn được dạy rằng xác định rõ ràng biến, thay vì sử dụng động, tối ưu hơn.

Bạn hiểu sai ý nghĩa của var. Đây là không phải theo bất kỳ cách nào động, vì nó tạo ra cùng một đầu ra. Nó chỉ có nghĩa là trình biên dịch định dạng kiểu cho biến đó bằng chính nó. Nó rõ ràng là có khả năng làm như vậy, vì đây là cơ chế tương tự được sử dụng để kiểm tra độ an toàn và độ chính xác của loại.

Nó cũng loại bỏ một bản sao mã hoàn toàn vô dụng. Đối với các loại đơn giản, điều này có thể không nhiều. Nhưng hãy xem xét:

SomeNamespace.AndSomeVeryLongTypeName foo = new SomeNamespace.AndSomeVeryLongTypeName(); 

Rõ ràng, trong trường hợp này tăng gấp đôi tên không chỉ là không cần thiết mà thực sự có hại.

+1

Cảm ơn bạn đã làm rõ về 'var' không giống như năng động, tôi đã không nhận ra điều đó. – JustinT

+1

+1 lời giải thích hay. – JonH

12

Không. Chúng phát ra chính xác IL.

Đó chỉ là vấn đề về phong cách.

var có lợi ích giúp bạn dễ dàng thay đổi kiểu trả về của hàm mà không thay đổi các phần khác của mã nguồn. Ví dụ: thay đổi kiểu trả về từ IEnumerable<T> thành List<T>. Tuy nhiên, nó có thể làm cho nó dễ dàng hơn để giới thiệu lỗi.

+6

Trên thực tế, đây là một sử dụng kém var. Nó chỉ nên được sử dụng khi loại là hiển nhiên từ ngữ cảnh. Nếu bạn có thể thay đổi kiểu trả về của một phương thức mà không thay đổi tên của nó thì bạn không nên sử dụng var vì kiểu liên quan không rõ ràng. –

+0

@Stephen: Tại sao nó xấu khi loại biểu thức không rõ ràng ngay lập tức? –

+3

Việc sử dụng var làm biểu tượng không rõ ràng làm giảm đáng kể khả năng đọc và dễ hiểu. Việc nắm bắt nhanh chóng loại đối tượng khi đọc mã dẫn đến việc hiểu nhanh hơn và cao hơn. –

8

Từ khóa var không thực sự khai báo biến có loại động. Biến vẫn được gõ tĩnh, nó chỉ nhập vào kiểu từ ngữ cảnh.

nó một phím tắt thoải mái khi bạn có một typename dài (typenames generic có thể dài)

+0

Điều chính là bạn không thể gán một int cho một var một thời điểm và một chuỗi tiếp theo, giống như bạn có thể với các loại động thực. Một khi loại được thiết lập, nó bị mắc kẹt theo cách đó. Bạn vẫn nhận được hỗ trợ đầy đủ intellisense và tất cả mọi thứ. –

1

Ít gõ = năng suất hơn :)

+3

Thực tế: Ít dễ đọc hơn = năng suất thấp hơn –

+3

Tốt, sau đó var là tốt hơn tất cả xung quanh. var thường dễ đọc hơn, đơn giản vì có ít đọc hơn để làm. –

+1

Các lần duy nhất mà var dễ đọc hơn là trong trường hợp tạo các đối tượng với các tên kiểu cực kỳ dài (thường là chung) như được đề xuất bởi Konrad. Có var có thể được kết hợp với loại gần như ngay lập tức và việc loại bỏ số lượng lớn các ký tự phụ giúp cải thiện khả năng hiểu. –

Các vấn đề liên quan