Helpex - Trao đổi & giúp đỡ Đăng nhập

Đến Var hoặc không tới Var

Hôm nay tôi được hỏi về việc sử dụng của tôi var var trong .NET. Khi nó xảy ra trong mọi cuộc tranh luận, tôi đã quên tất cả lý do tại sao tôi sử dụng phạm vi. Sau khi nghĩ về nó, lý do chính là, và sẽ luôn luôn là, tôi thích var .; nó giúp tôi tiết kiệm thời gian gõ các loại phức tạp hơn. Tôi chưa bao giờ thấy mình tự hỏi loại biến là gì, vì vậy tôi không quan tâm đến cách tôi khai báo kiểu của nó. Tôi chỉ quan tâm đến cách tôi sử dụng loại đó. Nhưng không giống như Jim Jeffries lập luận chung cho súng: Mạnh *! @ $ Bạn! Tôi thích súng!”(Như mô tả trong standup mình trên YouTube: https://www.youtube.com/watch?v=0rR9IaXH1M0 ), mà tôi đồng ý là một lập luận hoàn toàn hợp lệ để làm một cái gì đó, có nhiều lý do để sử dụng“ var. Vì vậy, tôi sẽ nói về từng người một.

  1. Nó dễ đọc như khai báo kiểu ngầm. Không có sự khác biệt cho dù bạn khai báo kiểu của bạn trước hay sau biến. Sau đây là như nhau.
    List<widgets> widgets;</widgets>

    var widgets = List<widgets>();</widgets>

  2. Tôi không phải lặp lại chính mình. Tôi lười biếng, thậm chí nhiều hơn khi tôi viết mã. Tôi có thể nhận được hai con chim bị ném đá cùng một lúc!
    var widgets = List<widgets>();</widgets>

    Dễ viết hơn thế này:
    List<widgets> widgets = new List<widget>();</widget></widgets>

  3. Tôi nhận được lợi ích của biến của tôi không bao giờ là null! Không có thêm tham chiếu Đối tượng nào không được đặt thành phiên bản của một đối tượng! Chắc chắn, đây không phải là vấn đề đối với các loại đơn giản như chuỗi, int, nhưng nó gây khó khăn cho các danh sách và danh sách như Danh sách . Đã bao nhiêu lần bạn khai báo danh sách của mình, quên khởi tạo nó, sau đó thử bỏ rác vào đó?! Tôi biết tôi có!
  4. Sử dụng các loại var var chỉ được phép sử dụng trong phạm vi cục bộ, điều đó có nghĩa là mỗi khi tôi khai báo một cái gì đó với loại var var, bạn biết rằng nó sẽ chỉ có sẵn trong phạm vi cục bộ. Cảm ơn đã chỉ ra điều ai cũng thấy!
  5. Tôi không quan tâm trình biên dịch làm gì với nó khi biên dịch! Đó không phải việc của tôi.

Một thanh bên về khả năng đọc mã

Vấn đề lớn hơn với khả năng đọc mà hầu hết mọi người đều bỏ lỡ, là cách bạn đặt tên cho các biến của mình và cách bạn cấu trúc mã của mình. Dưới đây là một số điều khiến mã khó đọc hơn nhiều:

  • Tên biến sau các chữ cái duy nhất. Có thể một số người có thể hiểu ý nghĩa của bạn nếu bạn viết mã, nhưng với bất kỳ ai mới nhìn vào nó, nó cũng có thể là tiếng Hy Lạp. Thật tuyệt nếu bạn là người Hy Lạp nhưng không quá nhiều cho những người khác. Làm thế nào về kết quả của Log Log hay hay?
  • Kích thước chức năng. Nếu chức năng của bạn lớn hơn một trang và tôi phải cuộn để đọc nó, bạn đang làm sai.
  • Viết hoa không nhất quán. Một tiêu chuẩn được chấp nhận rộng rãi là các tham số là camelCase, private _variabled là trường hợp nhỏ và có thể bắt đầu với từ _ _ và thuộc tính công cộng là trường hợp tiêu đề.
  • Quá nhiều thông số. Nếu một hàm có nhiều hơn 2-3 tham số, đã đến lúc tạo một đối tượng để truyền các tham số đó. Khả năng đọc đi ra ngoài cửa sổ khi các tham số chức năng bắt đầu kéo dài nhiều dòng.
  • Mô hình ngớ ngẩn mà bằng cách nào đó vẫn còn tồn tại. Bằng cách đó, tôi đang nói về các biến có chữ cái trong tên, chẳng hạn như ăn bFlag, hoặc iNumber. Một lựa chọn tốt hơn sẽ là Martin IsFlag. Hiện không có gì đạt được bằng cách chỉ định loại trong tên biến. IDE đã biết loại này và bạn có tất cả các thông tin liên quan đến loại đó.
  • Chuỗi đa dòng. SQL nội tuyến là con đẻ của việc này. Một cách tiếp cận tốt hơn một chút là đặt chuỗi đa dòng của bạn ở cuối lớp và sử dụng một số thay thế chuỗi để điền vào các giá trị của nó khi chạy. Sử dụng các chuỗi nguyên văn nếu bạn muốn các chuỗi nhiều dòng mà bạn có thể sao chép / dán ở những nơi khác. Hoặc tốt hơn, sử dụng ORM, đó là những gì họ đang làm!

Tín dụng

Tín dụng khi đến hạn, không theo thứ tự cụ thể: Burton Rheutan, Endurance Idehen, James Allen.

3 hữu ích 0 bình luận 9.4k xem chia sẻ

Có thể bạn quan tâm

loading