Xác định rõ ràng các loại dữ liệu biến so với sử dụng từ khóa 'var'? [đóng cửa]

Trong C #, tôi có được khuyến khích sử dụng từ khóa var đa mục đích cho mỗi khai báo biến không? Nếu có, tôi có phải đề cập đến các ký tự đặc biệt cho các giá trị bằng chữ trong khai báo biến như M cho số thập phân trong câu lệnh sau:

var myDecimal = 14.5M;

Nếu nó tạo ra sự khác biệt, tôi đang cố gắng thực hiện một số phát triển web với C #.

Đã có rất nhiều tranh chấp về việc sử dụng var. Quy tắc chung của tôi là như sau.

• Khi kiểu này là rõ ràng, chẳng hạn như khi bên phải của bài tập là một hàm tạo, sử dụng var.
• Khi loại phức tạp để viết, chẳng hạn như truy vấn LINQ (lý do cho var ở vị trí đầu tiên) sử dụng var.
• Đối với các kiểu không rõ ràng (Số thập phân của bạn là một ví dụ) trong đó bạn muốn đảm bảo rằng biến của bạn được nhập chính xác, hãy đánh vần nó.
• Các loại ẩn danh phải sử dụng var.
• Trong tất cả các trường hợp khác đánh vần các loại.

Về cơ bản, mục tiêu là để đọc mã dễ dàng hơn. Nếu bạn cảm thấy var đủ vì sự phân công rõ ràng, hãy sử dụng var. Sử dụng tên đầy đủ làm gợi ý cho người đọc khi bạn cảm thấy cần thiết.

Khi sử dụng varlà một chương trình "thánh chiến". Có chính xác một nơi mà nó được yêu cầu: khi kết quả của một hoạt động tạo ra một loại ẩn danh, chẳng hạn như:

var result = new { Name = "John", Age = 35 };

Bất cứ nơi nào khác, nó là tùy chọn và thực sự theo tiêu chuẩn mã hóa của bạn để sử dụng nó hay không trong các tình huống khác.

Và vâng, bạn sẽ cần các ký tự đặc biệt cho chữ để cho trình biên dịch biết nó ở phía bên tay phải. Trong ví dụ của bạn, không có M, mặc định là doublehơn decimal.

Từ MSDN :

Tuy nhiên, việc sử dụng var ít nhất có khả năng làm cho mã của bạn trở nên khó hiểu hơn đối với các nhà phát triển khác. Vì lý do đó, tài liệu C # thường chỉ sử dụng var khi được yêu cầu.

Tôi thực sự, thực sự không thích gõ ngầm. Nhìn bề ngoài, nó có xu hướng làm cho mã dễ đọc hơn, nhưng có thể dẫn đến nhiều vấn đề trong quá trình sử dụng. Nếu một nhà phát triển thay đổi một trình khởi tạo biến, giả sử, từ

var myFloat=100f;

đến

var myFloat=100;

hoặc là

var myFloat=100.0;

Loại sẽ thay đổi, dẫn đến toàn bộ hàng loạt lỗi biên dịch hoặc, nếu nó ở chế độ xem web và bạn không sử dụng bước hậu xây dựng để biên dịch trước các chế độ xem của mình, toàn bộ lỗi thời gian chạy sẽ không bị bắt mà không có hiệu quả thử nghiệm trước khi triển khai.

Gõ ngầm cũng không hoạt động ở mọi nơi (từ cùng một liên kết MSDN)

var chỉ có thể được sử dụng khi một biến cục bộ được khai báo và khởi tạo trong cùng một câu lệnh; biến không thể được khởi tạo thành null hoặc nhóm phương thức hoặc hàm ẩn danh.

var không thể được sử dụng trên các trường ở phạm vi lớp.

Các biến được khai báo bằng cách sử dụng var không thể được sử dụng trong biểu thức khởi tạo. Nói cách khác, biểu thức này là hợp pháp: int i = (i = 20); nhưng biểu thức này tạo ra lỗi thời gian biên dịch: var i = (i = 20);

Nhiều biến được gõ ngầm định không thể được khởi tạo trong cùng một câu lệnh.

Nếu một loại có tên var nằm trong phạm vi, thì từ khóa var sẽ phân giải thành tên loại đó và sẽ không được coi là một phần của khai báo biến cục bộ được gõ ngầm.

Giữ mã của bạn nhất quán (trong trường hợp này, sử dụng gõ rõ ràng ở mọi nơi) là một điều rất, rất tốt. Theo tôi, varlười biếng và không mang lại lợi ích thực sự, và đưa ra một điểm thất bại tiềm năng khác trong một quy trình vốn đã phức tạp.

Cập nhật 2017

Tôi hoàn toàn thay đổi suy nghĩ của mình. Khi làm việc trong C #, tôi sử dụng varhầu hết thời gian (ngoại trừ những thứ như biến kiểu giao diện, v.v.). Nó giữ mã terse giúp cải thiện khả năng đọc. Tuy nhiên, mặc dù - chú ý đến loại giải quyết thực sự là gì.

Tham chiếu C # hiển thị như sau để minh họa việc sử dụng tốt và xấu của cấu trúc này:

Ví dụ sau đây cho thấy hai biểu thức truy vấn. Trong biểu thức đầu tiên, việc sử dụng var được cho phép nhưng không bắt buộc, vì loại kết quả truy vấn có thể được nêu rõ ràng dưới dạng IEnumerable. Tuy nhiên, trong biểu thức thứ hai, var phải được sử dụng vì kết quả là một tập hợp các loại ẩn danh và tên của loại đó không thể truy cập được ngoại trừ chính trình biên dịch. Lưu ý rằng trong ví dụ # 2, mục biến lặp foreach cũng phải được gõ ngầm.

 // Example #1: var is optional because 
    // the select clause specifies a string 
    string[] words = { "apple", "strawberry", "grape", "peach", "banana" };
    var wordQuery = from word in words
                    where word[0] == 'g'
                    select word;

    // Because each element in the sequence is a string,  
    // not an anonymous type, var is optional here also. 
    foreach (string s in wordQuery)
    {
        Console.WriteLine(s);
    }

    // Example #2: var is required because 
    // the select clause specifies an anonymous type 
    var custQuery = from cust in customers
                    where cust.City == "Phoenix" 
                    select new { cust.Name, cust.Phone };

    // var must be used because each item  
    // in the sequence is an anonymous type 
    foreach (var item in custQuery)
    {
        Console.WriteLine("Name={0}, Phone={1}", item.Name, item.Phone);
    }

Từ khóa var chỉ yêu cầu trình biên dịch tự động suy ra loại biến var. Do đó, nếu bạn muốn lưu trữ một biến loại thập phân trong một biến var, bạn cần sử dụng m. Tương tự như vậy nếu bạn đang lưu trữ một chuỗi, bạn cần đặt nó trong dấu ngoặc kép.

Đối với tôi, tôi không sử dụng var cho các trường hợp sau:

• Khi tôi muốn chắc chắn về loại biến của mình (ví dụ để chắc chắn rằng loại được sử dụng là gấp đôi và không phải là số thập phân, và đây là một vấn đề lớn tin tưởng tôi!)
• Mã đa hình như thế nào Fruit foo = new Apple();. Trong trường hợp này, tôi nghĩ var là để tránh và sử dụng lớp cha (ở đây Fruit) tốt hơn bằng cách cho phép hiểu rõ hơn về logic mã và giới hạn của các lỗi có thể xảy ra (Với var, không kiểm tra khái niệm đa hình!)

Đối với phần còn lại, tôi nghĩ rằng nó phụ thuộc vào trường hợp và nền tảng của nhà phát triển. Một số người từ thế giới PHP sẽ không thích quan tâm đến các kiểu biến và một số người từ thế giới Java sẽ chỉ nghĩ var là một dị giáo và càng dài thì càng tốt.

Bạn sẽ phải đưa ra ý kiến ​​cá nhân của mình :)