Sử dụng từ khóa var trong C #

Sau khi thảo luận với các đồng nghiệp về việc sử dụng từ khóa 'var' trong C # 3, tôi tự hỏi ý kiến ​​của mọi người về cách sử dụng suy luận kiểu thông qua var là gì?

Ví dụ: tôi khá lười sử dụng var trong các trường hợp nghi vấn, ví dụ: -

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

Việc sử dụng var hợp pháp hơn như sau: -

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

Thú vị là LINQ dường như là một chút của một khu vực màu xám, ví dụ: -

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

Rõ ràng kết quả sẽ là gì khi nó sẽ là một kiểu thực hiện IEnumerable, tuy nhiên nó không hoàn toàn rõ ràng giống như cách một var khai báo một đối tượng mới.

Thậm chí còn tệ hơn khi nói đến LINQ cho các đối tượng, ví dụ: -

var results = from item in someList
              where item != 3
              select item;

Điều này không tốt hơn so với foreach tương đương (mục var trong someList) {// ...} tương đương.

Có một mối quan tâm thực sự về an toàn kiểu ở đây - ví dụ: nếu chúng ta đặt kết quả của truy vấn đó vào một phương thức quá tải chấp nhận IEnumerable <int> và IEnumerable <double> thì người gọi có thể vô tình chuyển nhầm loại.

var không duy trì kiểu gõ mạnh nhưng câu hỏi thực sự là liệu nó có nguy hiểm khi loại không rõ ràng ngay lập tức về định nghĩa hay không, điều gì đó được phóng to khi quá tải có nghĩa là lỗi trình biên dịch có thể không được đưa ra khi bạn vô tình chuyển sai loại cho phương thức.

Tôi vẫn nghĩ rằng varcó thể làm cho mã dễ đọc hơn trong một số trường hợp. Nếu tôi có một lớp Khách hàng có thuộc tính Đơn hàng và tôi muốn gán nó cho một biến, tôi sẽ chỉ làm điều này:

var orders = cust.Orders;

Tôi không quan tâm nếu Khách hàng. Các giao dịch là IEnumerable<Order>, ObservableCollection<Order>hoặc BindingList<Order>- tất cả những gì tôi muốn là giữ danh sách đó trong bộ nhớ để lặp lại hoặc lấy số liệu của nó hoặc một cái gì đó sau này.

Đối chiếu với tuyên bố trên với:

ObservableCollection<Order> orders = cust.Orders;

Đối với tôi, tên loại chỉ là tiếng ồn. Và nếu tôi quay lại và quyết định thay đổi loại Khách hàng. Hãy theo dõi (nói từ ObservableCollection<Order>thành IList<Order>) thì tôi cũng cần thay đổi tuyên bố đó - điều mà tôi sẽ không phải làm nếu tôi sử dụng var trong lần đầu tiên địa điểm.

Tôi sử dụng varrộng rãi. Đã có những chỉ trích rằng điều này làm giảm khả năng đọc của mã, nhưng không có đối số để hỗ trợ cho tuyên bố đó.

Phải thừa nhận rằng điều đó có nghĩa là chúng ta không rõ chúng ta đang đối phó với loại nào. Vậy thì sao? Đây thực sự là điểm của một thiết kế tách rời. Khi làm việc với các giao diện, bạn hoàn toàn không quan tâm đến loại mà một biến có. varđưa điều này đi xa hơn, đúng, nhưng tôi nghĩ rằng đối số vẫn giống nhau từ quan điểm dễ đọc: Lập trình viên thực sự không nên quan tâm đến loại biến mà là những gì một biến làm . Đây là lý do tại sao Microsoft cũng gọi kiểu gõ suy luận vịt gõ.

Vì vậy, một biến làm gì khi tôi khai báo nó bằng cách sử dụng var? Thật dễ dàng, nó làm bất cứ điều gì IntelliSense nói với tôi. Bất kỳ lý do nào về C # mà bỏ qua IDE đều thiếu thực tế. Trong thực tế, mọi mã C # được lập trình trong một IDE hỗ trợ IntelliSense.

Nếu tôi đang sử dụng một varbiến được khai báo và bị nhầm lẫn về biến đó là gì, thì về cơ bản có gì đó không đúng với mã của tôi. varkhông phải là nguyên nhân, nó chỉ làm cho các triệu chứng có thể nhìn thấy. Đừng đổ lỗi cho người đưa tin.

Bây giờ, nhóm C # đã phát hành một hướng dẫn mã hóa chỉvar nên được sử dụng để nắm bắt kết quả của câu lệnh LINQ tạo ra một loại ẩn danh (vì ở đây, chúng tôi không có giải pháp thay thế thực sự ). Vâng, vít đó. Miễn là nhóm C # không cung cấp cho tôi một lập luận hợp lý cho hướng dẫn này, tôi sẽ bỏ qua nó bởi vì theo quan điểm chuyên môn và cá nhân của tôi, đó là baloney thuần túy. (Xin lỗi; tôi không có liên kết đến hướng dẫn trong câu hỏi.)var

Trên thực tế, có một số giải thích tốt (bề ngoài) về lý do tại sao bạn không nên sử dụng varnhưng tôi vẫn tin rằng chúng phần lớn sai. Lấy ví dụ về tìm kiếm và tìm kiếm trên mạng: tác giả tuyên bố rằng varviệc tìm kiếm địa điểm MyTypeđược sử dụng khó khăn . Đúng. Giao diện cũng vậy. Trên thực tế, tại sao tôi muốn biết lớp được sử dụng ở đâu? Tôi có thể quan tâm nhiều hơn đến nơi nó được khởi tạo và điều này vẫn có thể tìm kiếm được bởi vì ở đâu đó, hàm tạo của nó phải được gọi (ngay cả khi điều này được thực hiện gián tiếp, tên loại phải được đề cập ở đâu đó).

Var, theo tôi, trong C # là một điều tốt ^tm . Bất kỳ biến nào được gõ vẫn được gõ mạnh, nhưng nó được loại từ phía bên phải của bài tập được xác định. Bởi vì thông tin loại có sẵn ở phía bên tay phải, trong hầu hết các trường hợp, không cần thiết và quá dài dòng cũng phải nhập thông tin ở phía bên trái. Tôi nghĩ rằng điều này làm tăng đáng kể khả năng đọc mà không giảm an toàn loại.

Từ quan điểm của tôi, sử dụng các quy ước đặt tên tốt cho các biến và phương thức là quan trọng hơn từ góc độ dễ đọc hơn thông tin loại rõ ràng. Nếu tôi cần thông tin loại, tôi luôn có thể di chuột qua biến (trong VS) và lấy nó. Nói chung, mặc dù, thông tin loại rõ ràng không cần thiết cho người đọc. Đối với nhà phát triển, trong VS bạn vẫn nhận được Intellisense, bất kể biến được khai báo như thế nào. Đã nói tất cả những điều đó, vẫn có thể có trường hợp tuyên bố rõ ràng kiểu này - có lẽ bạn có một phương thức trả về a List<T>, nhưng bạn muốn coi nó như mộtIEnumerable<T>trong phương pháp của bạn. Để đảm bảo rằng bạn đang sử dụng giao diện, việc khai báo biến của loại giao diện có thể làm cho điều này rõ ràng. Hoặc, có lẽ, bạn muốn khai báo một biến không có giá trị ban đầu - bởi vì nó ngay lập tức nhận được một giá trị dựa trên một số điều kiện. Trong trường hợp đó bạn cần loại. Nếu thông tin loại là hữu ích hoặc cần thiết, hãy tiếp tục và sử dụng nó. Mặc dù vậy, tôi cảm thấy rằng điều đó thường không cần thiết và mã dễ đọc hơn trong hầu hết các trường hợp.

Cả hai điều đó đều hoàn toàn đúng; varcó thể có cả tác động tích cực và tiêu cực đến khả năng đọc. Theo tôi, varnên được sử dụng khi một trong những điều sau đây là đúng:

1. Loại này là ẩn danh (tốt, bạn không có lựa chọn nào ở đây, vì nó phải là var trong trường hợp này)
2. Kiểu này là rõ ràng dựa trên biểu thức được gán (tức là var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

varkhông có tác động hiệu suất, vì nó là cú pháp đường; trình biên dịch nhập kiểu và định nghĩa nó một khi nó được biên dịch thành IL; không có gì thực sự năng động về nó.

Từ Eric Lippert, một Kỹ sư thiết kế phần mềm cao cấp trong nhóm C #:

Tại sao vartừ khóa được giới thiệu?

Có hai lý do, một lý do tồn tại ngày nay, một lý do sẽ tăng lên trong 3.0.

Lý do đầu tiên là mã này cực kỳ xấu vì tất cả sự dư thừa:

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

Và đó là một ví dụ đơn giản - tôi đã viết tệ hơn. Bất cứ khi nào bạn buộc phải nhập chính xác cùng một thứ hai lần, đó là sự dư thừa mà chúng ta có thể loại bỏ. Viết đẹp hơn nhiều

var mylists = new Dictionary<string,List<int>>();

và để trình biên dịch tìm ra loại dựa trên sự phân công.

Thứ hai, C # 3.0 giới thiệu các loại ẩn danh. Vì các loại ẩn danh theo định nghĩa không có tên, bạn cần có thể suy ra loại biến từ biểu thức khởi tạo nếu loại của nó là ẩn danh.

Nhấn mạnh mỏ. Toàn bộ bài viết, C # 3.0 vẫn được gõ tĩnh, trung thực! , và loạt tiếp theo là khá tốt.

Đây là những gì vardành cho. Các ứng dụng khác có thể sẽ không hoạt động tốt. Bất kỳ so sánh với JScript, VBScript hoặc gõ động là tổng số bunk. Lưu ý một lần nữa, varlà bắt buộc để có một số tính năng khác hoạt động trong .NET.

Tôi nghĩ rằng việc sử dụng var nên được kết hợp với các tên biến được chọn một cách khôn ngoan.

Tôi không có vấn đề gì khi sử dụng var trong một tuyên bố foreach, miễn là nó không như thế này:

foreach (var c in list) { ... }

Nếu nó giống như thế này:

foreach (var customer in list) { ... }

... sau đó ai đó đọc mã sẽ có nhiều khả năng hiểu "danh sách" là gì. Nếu bạn có quyền kiểm soát tên của biến danh sách, điều đó thậm chí còn tốt hơn.

Điều tương tự có thể áp dụng cho các tình huống khác. Điều này khá vô dụng:

var x = SaveFoo(foo);

... nhưng điều này có ý nghĩa:

var saveSucceeded = SaveFoo(foo);

Mỗi người để riêng mình, tôi đoán. Tôi đã thấy mình làm điều này, điều đó thật điên rồ:

var f = (float)3;

Tôi cần một số loại chương trình var 12 bước. Tên tôi là Matt và tôi (ab) sử dụng var.

Chúng tôi đã áp dụng ethos "Mã cho mọi người, không phải máy móc", dựa trên giả định rằng bạn dành nhiều thời gian hơn trong chế độ bảo trì nhiều lần so với phát triển mới.

Đối với tôi, điều đó loại trừ đối số mà trình biên dịch "biết" loại biến là gì - chắc chắn, bạn không thể viết mã không hợp lệ ngay lần đầu tiên vì trình biên dịch ngăn mã của bạn biên dịch, nhưng khi nhà phát triển tiếp theo đang đọc mã trong 6 tháng thời gian họ cần có thể suy ra những gì biến đang làm đúng hoặc không chính xác và nhanh chóng xác định nguyên nhân của các vấn đề.

Như vậy

var something = SomeMethod();

bị đặt ra ngoài vòng pháp luật bởi các tiêu chuẩn mã hóa của chúng tôi, nhưng những điều sau đây được khuyến khích trong nhóm của chúng tôi vì nó làm tăng khả năng đọc:

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

Nó không tệ, nó là một thứ phong cách, có xu hướng chủ quan. Nó có thể thêm sự không nhất quán, khi bạn sử dụng var và khi bạn không sử dụng.

Một trường hợp đáng quan tâm khác, trong cuộc gọi sau, bạn không thể biết chỉ bằng cách xem mã loại được trả về bởi CallMe:

var variable = CallMe();

Đó là khiếu nại chính của tôi chống lại var.

Tôi sử dụng var khi tôi khai báo các đại biểu ẩn danh trong các phương thức, bằng cách nào đó var trông sạch hơn so với khi tôi sử dụng Func. Xem xét mã này:

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

EDIT : Cập nhật mẫu mã cuối cùng dựa trên đầu vào của Julian

Var không giống như biến thể chút nào. Biến vẫn được gõ mạnh, chỉ là bạn không nhấn phím để hiểu theo cách đó. Bạn có thể di chuột qua nó trong Visual Studio để xem loại. Nếu bạn đang đọc mã in, có thể bạn phải suy nghĩ một chút để biết loại này là gì. Nhưng chỉ có một dòng khai báo nó và nhiều dòng sử dụng nó, vì vậy việc đặt tên cho những thứ đàng hoàng vẫn là cách tốt nhất để làm cho mã của bạn dễ theo dõi hơn.

Là sử dụng Intellisense lười biếng? Nó ít gõ hơn toàn bộ tên. Hoặc có những thứ ít làm việc hơn nhưng không đáng bị chỉ trích? Tôi nghĩ là có, và var là một trong số đó.

Thời gian rất có thể bạn sẽ cần điều này là cho các loại ẩn danh (trong đó yêu cầu 100%); nhưng nó cũng tránh sự lặp lại cho các trường hợp tầm thường và IMO làm cho dòng rõ ràng hơn. Tôi không cần phải xem loại hai lần để khởi tạo đơn giản.

Ví dụ:

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(vui lòng không chỉnh sửa hscroll ở trên - điều này chứng tỏ quan điểm !!!)

vs

var data = new Dictionary<string, List<SomeComplexType<int>>>();

Tuy nhiên, có những trường hợp khi điều này gây hiểu lầm và có khả năng gây ra lỗi. Hãy cẩn thận varkhi sử dụng nếu biến ban đầu và loại khởi tạo không giống nhau. Ví dụ:

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

Một trường hợp cụ thể mà var rất khó: đánh giá mã ngoại tuyến, đặc biệt là những đánh giá được thực hiện trên giấy.

Bạn không thể dựa vào chuột cho điều đó.

Tôi không thấy vấn đề lớn là gì ..

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

Bạn vẫn có đầy đủ thông tin về 'một cái gì đó', và đối với bất kỳ trường hợp mơ hồ nào, bạn có bài kiểm tra đơn vị của mình, phải không? (phải không?)

Nó không phải là varchar, nó không mờ và chắc chắn nó không phải là kiểu gõ động hay yếu. Nó đang dừng maddnes như thế này:

List<somethinglongtypename> v = new List<somethinglongtypename>();

và giảm tổng số suy nghĩ đó xuống:

var v = new List<somethinglongtypename>();

Đẹp, không đẹp bằng:

v = List<somethinglongtypename>();

Nhưng đó là những gì Boo dành cho.

Nếu ai đó đang sử dụng vartừ khóa vì họ không muốn "tìm ra loại", đó chắc chắn là lý do sai. Cácvar từ khóa không tạo ra một biến với một loại năng động, trình biên dịch vẫn phải biết loại. Vì biến luôn có một loại cụ thể, nên loại này cũng được hiển thị trong mã nếu có thể.

Những lý do tốt để sử dụng vartừ khóa là ví dụ:

• Khi cần, nghĩa là khai báo một tham chiếu cho một loại ẩn danh.
• Trong đó nó làm cho mã dễ đọc hơn, tức là loại bỏ các khai báo lặp lại.

Viết ra kiểu dữ liệu thường làm cho mã dễ theo dõi hơn. Nó hiển thị loại dữ liệu bạn đang sử dụng, do đó bạn không phải tìm ra loại dữ liệu bằng cách đầu tiên tìm ra mã này làm gì.

Hiện tại Intellisense mạnh đến mức nào, tôi không chắc var khó đọc hơn việc có các biến thành viên trong một lớp hay các biến cục bộ trong một phương thức được xác định ngoài vùng màn hình hiển thị.

Nếu bạn có một dòng mã như

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Là dễ dàng hơn hoặc khó đọc hơn:

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Tôi nghĩ điều quan trọng với VAR là chỉ sử dụng nó khi thích hợp tức là khi thực hiện mọi thứ trong Linq mà nó tạo điều kiện (và có thể trong các trường hợp khác).

Nếu bạn có một loại cho một cái gì đó thì bạn nên sử dụng nó - không nên làm như vậy là sự lười biếng đơn giản (trái ngược với sự lười biếng sáng tạo thường được khuyến khích - các lập trình viên giỏi thường rất khó để lười biếng và có thể được xem xét nguồn gốc của sự vật ở nơi đầu tiên).

Lệnh cấm chăn cũng tệ như lạm dụng cấu trúc ở nơi đầu tiên nhưng cần phải có một tiêu chuẩn mã hóa hợp lý.

Một điều khác cần nhớ là nó không phải là một kiểu var VB trong đó nó không thể thay đổi các loại - đó là một biến được gõ mạnh, chỉ là loại được suy ra (đó là lý do tại sao có những người sẽ cho rằng nó không hợp lý với sử dụng nó trong giả sử, nhưng tôi không đồng ý vì lý do cả khả năng đọc và khả năng bảo trì).

Tôi nghi ngờ cái này sẽ chạy và chạy (-:

Murph

Chắc chắn, intlà dễ dàng, nhưng khi kiểu của biến là IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var làm cho mọi thứ dễ dàng hơn nhiều.

Bị đánh cắp từ bài đăng về vấn đề này tại CodingHorror :

Thật không may, bạn và những người khác khá nhiều đã hiểu sai. Mặc dù tôi đồng ý với bạn rằng sự dư thừa không phải là một điều tốt, nhưng cách tốt hơn để giải quyết vấn đề này sẽ là làm một việc như sau:

Nicholas Paldino .NET / C # MVP vào ngày 20 tháng 6 năm 2008 08:00 AM

Tôi đoán nếu mối quan tâm chính của bạn là phải gõ ít hơn - thì sẽ không có bất kỳ đối số nào sẽ khiến bạn sử dụng nó.

Nếu bạn chỉ sẽ bao giờ có người nhìn vào mã của bạn, sau đó ai quan tâm? Mặt khác, trong trường hợp như thế này:

var people = Managers.People

không sao, nhưng trong trường hợp như thế này:

var fc = Factory.Run();

nó làm chập mạch mọi kiểu khấu trừ tức thời mà não tôi có thể bắt đầu hình thành từ 'tiếng Anh' của mã.

Mặt khác, chỉ cần sử dụng phán đoán và lập trình 'lịch sự' tốt nhất của bạn đối với những người khác có thể phải làm việc trong dự án của bạn.

Sử dụng varthay vì loại rõ ràng làm cho tái cấu trúc dễ dàng hơn nhiều (do đó tôi phải mâu thuẫn với các áp phích trước đó có nghĩa là nó không có sự khác biệt hoặc nó hoàn toàn là "đường cú pháp").

Bạn có thể thay đổi kiểu trả về của các phương thức của bạn mà không thay đổi mọi tệp nơi phương thức này được gọi. Hãy tưởng tượng

...
List<MyClass> SomeMethod() { ... }
...

được sử dụng như

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

Nếu bạn muốn cấu trúc lại SomeMethod()để trả về một IEnumerable<MySecondClass>, bạn sẽ phải thay đổi khai báo biến (cũng bên trongforeach ) ở mọi nơi bạn đã sử dụng phương thức.

Nếu bạn viết

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

thay vào đó, bạn không phải thay đổi nó.

@aku: Một ví dụ là đánh giá mã. Một ví dụ khác là tái cấu trúc các kịch bản.

Về cơ bản, tôi không muốn đi săn bằng chuột. Nó có thể không có sẵn.

Đó là một vấn đề của hương vị. Tất cả sự ồn ào này về loại biến sẽ biến mất khi bạn quen với các ngôn ngữ được gõ động. Đó là, nếu bạn đã từng bắt đầu thích chúng (Tôi không chắc mọi người có làm được không, nhưng tôi thì có).

C # 's varkhá thú vị ở chỗ nó trông giống như gõ động, nhưng thực sự là gõ tĩnh - trình biên dịch thực thi đúng cách sử dụng.

Loại biến của bạn không thực sự quan trọng (điều này đã được nói trước đây). Nó phải tương đối rõ ràng từ ngữ cảnh (tương tác của nó với các biến và phương thức khác) và tên của nó - đừng mong đợi danh sách khách hàng có chứa một int...

Tôi vẫn đang chờ xem ông chủ của tôi nghĩ gì về vấn đề này - tôi đã lấy một chiếc chăn "đi trước" để sử dụng bất kỳ cấu trúc mới nào trong 3.5, nhưng chúng tôi sẽ làm gì về bảo trì?

Trong so sánh giữa bạn IEnumerable<int>và IEnumerable<double>bạn không cần phải lo lắng - nếu bạn chuyển sai loại, mã của bạn sẽ không được biên dịch.

Không có mối quan tâm về loại an toàn, như varlà không năng động. Đó chỉ là ma thuật biên dịch và bất kỳ loại cuộc gọi không an toàn nào bạn thực hiện sẽ bị bắt.

Var là hoàn toàn cần thiết cho Linq:

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

Bây giờ hãy nhìn vào anonEnumutions trong intellisense và nó sẽ xuất hiện một cái gì đó nhưIEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

Trình biên dịch C # khá thông minh - các loại anon được tạo riêng sẽ có cùng loại được tạo nếu thuộc tính của chúng khớp.

Bên ngoài đó, miễn là bạn có intellisense, nó có ý nghĩa tốt để sử dụng varbất cứ nơi nào bối cảnh rõ ràng.

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

Tôi đoán nó phụ thuộc vào quan điểm của bạn. Cá nhân tôi chưa bao giờ gặp khó khăn khi hiểu một đoạn mã vì var"sử dụng sai" và đồng nghiệp của tôi và tôi sử dụng nó khá nhiều. (Tôi đồng ý rằng Intellisense là một trợ giúp rất lớn trong vấn đề này.) Tôi hoan nghênh nó như là một cách để loại bỏ hành trình lặp đi lặp lại.

Rốt cuộc, nếu tuyên bố như

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

thực sự là không thể đối phó, không ai sẽ sử dụng các ngôn ngữ được gõ động.

Tôi chỉ sử dụng var khi nó rõ ràng để xem loại nào được sử dụng.

Ví dụ: tôi sẽ sử dụng var trong trường hợp này, bởi vì bạn có thể thấy ngay rằng x sẽ thuộc loại "MyClass":

var x = new MyClass();

Tôi sẽ KHÔNG sử dụng var trong các trường hợp như thế này, vì bạn phải kéo chuột qua mã và nhìn vào tooltip để xem loại MyFactor trả về loại nào:

var x = MyClass.MyFunction();

Đặc biệt, tôi không bao giờ sử dụng var trong trường hợp phía bên phải thậm chí không phải là một phương thức, mà chỉ là một giá trị:

var x = 5;

(vì trình biên dịch không thể biết nếu tôi muốn một byte, short, int hay gì nữa)

Đối với tôi, ác cảm đối với việc varminh họa tại sao song ngữ trong .NET lại quan trọng. Đối với những lập trình viên C # cũng đã thực hiện VB .NET, những lợi thế của vartrực giác là rõ ràng. Khai báo C # tiêu chuẩn của:

List<string> whatever = new List<string>();

là tương đương, trong VB .NET, khi gõ này:

Dim whatever As List(Of String) = New List(Of String)

Không ai làm điều đó trong VB .NET. Sẽ thật ngớ ngẩn, bởi vì phiên bản .NET đầu tiên bạn đã có thể làm điều này ...

Dim whatever As New List(Of String)

... Nó tạo ra biến và khởi tạo tất cả trong một dòng nhỏ gọn hợp lý. Ah, nhưng nếu bạn muốn một IList<string>, không phải là một List<string>? Chà, trong VB .NET có nghĩa là bạn phải làm điều này:

Dim whatever As IList(Of String) = New List(Of String)

Giống như bạn phải làm trong C # và rõ ràng không thể sử dụng varcho:

IList<string> whatever = new List<string>();

Nếu bạn cần loại là một cái gì đó khác nhau, nó có thể được. Nhưng một trong những nguyên tắc cơ bản của lập trình tốt là giảm sự dư thừa, và đó chính xác là những gì var làm.

Sử dụng nó cho các loại ẩn danh - đó là những gì nó có. Bất cứ điều gì khác là sử dụng quá xa. Giống như nhiều người lớn lên trên C, tôi thường nhìn vào bên trái của tờ khai cho loại. Tôi không nhìn vào phía bên phải trừ khi tôi phải làm thế. Sử dụng varcho bất kỳ tuyên bố cũ nào khiến tôi làm điều đó mọi lúc, điều mà cá nhân tôi thấy không thoải mái.

Những người nói rằng 'không thành vấn đề, hãy sử dụng những gì bạn hài lòng' sẽ không nhìn thấy toàn bộ bức tranh. Mọi người sẽ nhận mã của người khác vào lúc này hay lúc khác và phải đối phó với bất kỳ quyết định nào họ đưa ra tại thời điểm họ viết nó. Thật tệ khi phải đối phó với các quy ước đặt tên hoàn toàn khác nhau, hoặc - kiểu kẹp cổ điển - kiểu giằng, mà không thêm toàn bộ điều ' varhoặc không' vào hỗn hợp. Trường hợp xấu nhất sẽ là nơi một lập trình viên không sử dụng varvà sau đó là một người bảo trì yêu thích nó và mở rộng mã sử dụng nó. Vì vậy, bây giờ bạn có một mớ hỗn độn không lành mạnh.

Các tiêu chuẩn là một điều tốt chính xác bởi vì chúng có nghĩa là bạn có nhiều khả năng có thể nhận mã ngẫu nhiên và có thể mò mẫm nó một cách nhanh chóng. Càng nhiều thứ khác biệt, càng khó. Và việc chuyển sang phong cách 'var ở mọi nơi' tạo nên sự khác biệt lớn .

Tôi không ngại gõ động, và tôi không ngại gõ phím - trong các ngôn ngữ được thiết kế cho chúng. Tôi khá thích Python. Nhưng C # được thiết kế như một ngôn ngữ được gõ rõ ràng tĩnh và đó là cách nó nên tồn tại. Phá vỡ các quy tắc cho các loại ẩn danh là đủ xấu; cho phép mọi người tiếp tục phát triển hơn nữa và phá vỡ các thành ngữ của ngôn ngữ hơn nữa là điều tôi không hài lòng. Bây giờ vị thần đã ra khỏi chai, nó sẽ không bao giờ quay trở lại. C # sẽ bị balkan thành trại. Không tốt.

Nhiều lần trong quá trình thử nghiệm, tôi thấy mình có mã như thế này:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

Bây giờ, đôi khi, tôi sẽ muốn xem một số thứ mà chính nó chứa, một số khác không phải là loại mà CallMethod () trả về. Vì tôi đang sử dụng var, nên tôi chỉ thay đổi điều này:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

đến đây:

var something = myObject.SomeProperty.SomeOtherThing;

Nếu không có var, tôi cũng phải tiếp tục thay đổi kiểu khai báo ở phía bên trái. Tôi biết nó là nhỏ, nhưng nó cực kỳ thuận tiện.

Đối với các afficionados nghĩ rằng vartiết kiệm thời gian, cần ít thao tác gõ phím hơn:

StringBuilder sb = new StringBuilder();

hơn

var sb = new StringBuilder();

Đếm em nếu em không tin anh ...

19 so với 21

Tôi sẽ giải thích nếu tôi phải, nhưng chỉ cần thử nó ... (tùy thuộc vào trạng thái hiện tại của bạn, bạn có thể phải nhập thêm một vài cho mỗi người)

Và nó đúng với mọi loại bạn có thể nghĩ đến !!

Cảm nhận cá nhân của tôi là var không bao giờ nên được sử dụng trừ trường hợp không biết loại này vì nó làm giảm khả năng đọc nhận dạng trong mã. Bộ não mất nhiều thời gian hơn để nhận ra loại hơn là một dòng đầy đủ. Đồng hồ cũ, những người hiểu mã máy và bit biết chính xác những gì tôi đang nói. Bộ não xử lý song song và khi bạn sử dụng var, bạn buộc nó phải tuần tự hóa đầu vào của nó. Tại sao bất cứ ai cũng muốn làm cho bộ não của họ làm việc chăm chỉ hơn? Đó là những gì máy tính dành cho.

Tôi chia var ở khắp mọi nơi, những nơi đáng nghi duy nhất đối với tôi là các loại ngắn nội bộ, ví dụ: tôi thích int i = 3;hơnvar i = 3;

Nó chắc chắn có thể làm cho mọi thứ đơn giản hơn, từ mã tôi đã viết ngày hôm qua:

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

Điều này sẽ cực kỳ dài dòng mà không có var.

Phụ lục: Một ít thời gian dành cho một ngôn ngữ có suy luận kiểu thực (ví dụ F #) sẽ cho thấy trình biên dịch tốt như thế nào để có được loại biểu thức đúng. Nó chắc chắn có nghĩa là tôi có xu hướng sử dụng varnhiều nhất có thể, và sử dụng một loại rõ ràng bây giờ chỉ ra rằng biến không phải là loại của biểu thức khởi tạo.

Không, ngoại trừ việc bạn không phải viết tên loại hai lần. http://msdn.microsoft.com/en-us/l Library / bb383973.aspx