Để gạch dưới hoặc không gạch dưới, đó là câu hỏi

Có bất kỳ vấn đề nào khi không thêm tiền tố vào các trường riêng với dấu gạch dưới trong C # nếu phiên bản nhị phân sẽ bị các ngôn ngữ khung khác sử dụng không? Ví dụ: vì C # phân biệt chữ hoa chữ thường, bạn có thể gọi một trường "foo" và thuộc tính công khai là "Foo" và nó hoạt động tốt.

Điều này sẽ có bất kỳ ảnh hưởng đến một ngôn ngữ case-insensitive như VB.NET, sẽ có bởi bất kỳ CLS tuân thủ (hoặc khác) vấn đề nếu những cái tên chỉ phân biệt bởi vỏ?

Nó sẽ không có hiệu lực.

Một phần trong các khuyến nghị để viết thư viện tuân thủ CLS là KHÔNG có hai thực thể công khai / được bảo vệ chỉ khác nhau theo từng trường hợp, ví dụ như bạn KHÔNG nên có

public void foo() {...}

và

public void Foo() {...}

những gì bạn mô tả không phải là vấn đề vì mục riêng tư không có sẵn cho người dùng thư viện

CẬP NHẬT QUAN TRỌNG (ngày 12 tháng 4 năm 2016):

Chúng tôi đã nhận thấy rằng tiêu chuẩn nội bộ của nhóm .NET CoreFX khăng khăng sử dụng ký hiệu gạch dưới mà không đưa ra bất kỳ hiểu biết nào về lý do tại sao. Tuy nhiên, nếu chúng ta nhìn kỹ vào quy tắc # 3 nó trở nên rõ ràng rằng có một hệ thống _, t_, s_tiền tố cho thấy lý do tại sao _được chọn ở nơi đầu tiên.

3. Chúng tôi sử dụng _camelCasecho các lĩnh vực nội bộ và tư nhân và sử dụng chỉ đọc khi có thể. Các trường tiền tố với _, các trường tĩnh với s_và các trường tĩnh của luồng với t_. Khi được sử dụng trên các trường tĩnh, readonlynên đến sau static(tức là static readonlykhông readonly static).
4. Chúng tôi tránh this.trừ khi thực sự cần thiết.

Vì vậy, nếu bạn giống như nhóm .NET CoreFX làm việc với một số mã cấp độ hệ thống quan trọng, đa luồng, cấp độ hệ thống , thì đó chính là BỀN VỮNG mà bạn:

• tuân thủ các tiêu chuẩn mã hóa của họ và
• sử dụng ký hiệu gạch dưới và
• đừng đọc câu trả lời này nữa

Nếu không xin vui lòng đọc trên ...

CÂU TRẢ LỜI GỐC:

Trước tiên hãy đồng ý về những gì chúng ta đang nói về. Câu hỏi là làm thế nào chúng ta truy cập các thành viên thể hiện từ bên trong các phương thức và hàm tạo không tĩnh của một lớp / lớp con nếu các bộ điều chỉnh mức độ hiển thị cho phép làm như vậy.

Ký hiệu gạch dưới

• đề nghị bạn sử dụng tiền tố "_" trong tên của các trường riêng
• nó cũng nói rằng bạn không bao giờ nên sử dụng "cái này" trừ khi thật cần thiết

Ký hiệu này

• đề nghị bạn chỉ luôn luôn sử dụng "này." để truy cập bất kỳ thành viên cá thể

Tại sao ký hiệu này tồn tại?

Bởi vì đây là cách bạn

• phân biệt một tham số từ một trường khi chúng có cùng tên
• đảm bảo bạn đang làm việc trong bối cảnh của trường hợp hiện tại

Thí dụ

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Tại sao ký hiệu gạch dưới tồn tại?

Một số người không thích gõ "cái này", nhưng họ vẫn cần một cách để phân biệt một trường và một tham số, vì vậy họ đã đồng ý sử dụng "_" trước một trường

Thí dụ

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Người ta có thể nghĩ rằng đó chỉ là vấn đề sở thích cá nhân và cả hai cách đều tốt / xấu như nhau. Tuy nhiên, có một số khía cạnh nhất định trong đó ký hiệu này đánh bại ký hiệu gạch dưới:

Trong trẻo

• tên ký tự gạch dưới
• ký hiệu này giữ nguyên tên

Tải nhận thức

• ký hiệu gạch dưới không nhất quán, nó làm cho bạn xử lý các trường theo một cách đặc biệt, nhưng bạn không thể sử dụng nó với các thành viên khác, mỗi khi bạn cần tự hỏi liệu bạn cần một tài sản hay một lĩnh vực

• ký hiệu này là nhất quán, bạn không cần phải suy nghĩ, bạn chỉ cần luôn sử dụng "cái này" để chỉ bất kỳ thành viên nào

CẬP NHẬT: như đã chỉ ra sau đây không phải là một điểm lợi thế

Bảo trì

• ký hiệu gạch dưới yêu cầu bạn phải để mắt _trong khi tái cấu trúc, nói rằng biến một trường thành thuộc tính (loại bỏ _) hoặc ngược lại (thêm _)

• ký hiệu này không có vấn đề như vậy

Tự động hoàn thành

Khi bạn cần xem danh sách các thành viên thể hiện:

• ký hiệu gạch dưới không giúp bạn nhiều, bởi vì khi bạn gõ "_", cửa sổ bật lên tự động hoàn thành sẽ hiển thị cho bạn các trường riêng và tất cả các loại có sẵn từ các hội đồng được liên kết trộn với phần còn lại của các thành viên thể hiện
• ký hiệu này cung cấp cho bạn một câu trả lời rõ ràng, bằng cách nhập "này" tất cả những gì bạn thấy là danh sách các thành viên và không có gì khác

Sự mơ hồ

Đôi khi bạn phải xử lý mã mà không cần sự trợ giúp của Intellisense. Ví dụ khi bạn thực hiện đánh giá mã hoặc duyệt mã nguồn trực tuyến.

• ký hiệu gạch dưới là mơ hồ: Khi bạn thấy Something.S SomethingElse bạn không thể biết liệu Something là một lớp và SomethingElse là thuộc tính tĩnh của nó ... hoặc có thể Something là một thuộc tính hiện tại có thuộc tính riêng của SomethingElse

• ký hiệu này là rõ ràng: Khi bạn thấy Something.S SomethingElse, nó chỉ có thể có nghĩa là một lớp có thuộc tính tĩnh và khi bạn nhìn thấy cái này. Something.S SomethingElse bạn biết rằng Something là thành viên và SomethingElse là thuộc tính của nó

Phương pháp mở rộng

Bạn không thể sử dụng các phương thức tiện ích mở rộng trên chính cá thể mà không sử dụng "this."

• ký hiệu gạch dưới yêu cầu bạn không sử dụng "cái này", tuy nhiên với các phương thức mở rộng bạn phải
• ký hiệu này giúp bạn tránh khỏi sự do dự, bạn luôn sử dụng "này", giai đoạn.

Hỗ trợ Visual Studio

• ký hiệu gạch dưới không có hỗ trợ tích hợp trong Visual Studio

• ký hiệu này được Visual Studio hỗ trợ một cách tự nhiên:

  1. "Điều này." Trình độ chuyên môn : Thích tất cả các trường không tĩnh được sử dụng trong các phương thức không tĩnh được mở đầu bằng this.C #

Khuyến nghị chính thức

Có rất nhiều hướng dẫn chính thức nói rõ ràng "không sử dụng dấu gạch dưới", đặc biệt là trong C #

• ký hiệu gạch dưới xuất phát từ C ++, đây là một thông lệ chung giúp tránh xung đột đặt tên, VisualBasic.Net cũng được đề xuất để khắc phục sự cố trong đó một trường "giá trị" và thuộc tính "Giá trị" thực sự có cùng tên, vì VisualBasic không phân biệt chữ hoa chữ thường

  1. Tên phần tử được khai báo trong Visual Basic
  2. Các trường sao lưu trong VisualBasic.NET

• ký hiệu này được khuyến nghị cho C # trong khi "_" bị cấm rõ ràng:

  1. từ khóa này trong C #
  2. Hướng dẫn sử dụng trường : Không áp dụng tiền tố cho tên trường hoặc tên trường tĩnh.
  3. Nguyên tắc cho tên: Tên của các thành viên loại : Không sử dụng tiền tố cho tên trường.
  4. Quy ước đặt tên chung : X KHÔNG sử dụng dấu gạch dưới, dấu gạch nối hoặc bất kỳ ký tự không chữ và số nào khác
  5. Quy tắc khẳng định chất lượng CA1707 : Mã định danh không được chứa dấu gạch dưới
  6. Sử dụng dấu gạch dưới không tuân thủ CLS (đối với định danh công khai và được bảo vệ)
  7. Quy ước đặt tên nội bộ của nhà phát triển .NET Framework : Không sử dụng tiền tố cho các biến thành viên. Nếu bạn muốn phân biệt giữa các biến cục bộ và biến thành viên, bạn nên sử dụng "this." trong C # và "Tôi." trong VB.NET.

Lấy từ tệp Trợ giúp Microsoft StyleCop:

Loại Tên: FieldNamesMustNotBeginWithUnderscore

Kiểm tra: SA1309

Nguyên nhân: Tên trường trong C # bắt đầu bằng dấu gạch dưới.

Mô tả quy tắc:

Vi phạm quy tắc này xảy ra khi tên trường bắt đầu bằng dấu gạch dưới.

Theo mặc định, StyleCop không cho phép sử dụng dấu gạch dưới, m_, v.v., để đánh dấu các trường lớp cục bộ, có lợi cho 'cái này'. tiếp đầu ngữ. Ưu điểm của việc sử dụng 'này.' là nó áp dụng như nhau cho tất cả các loại phần tử bao gồm các phương thức, thuộc tính, v.v. và không chỉ các trường, làm cho tất cả các lệnh gọi đến các thành viên lớp có thể nhận ra ngay lập tức, bất kể trình soạn thảo nào đang được sử dụng để xem mã. Một ưu điểm khác là nó tạo ra sự khác biệt nhanh chóng, dễ nhận biết giữa các thành viên thể hiện và thành viên tĩnh, sẽ không bị tiền tố.

Nếu trường hoặc tên biến được dự định khớp với tên của một mục được liên kết với Win32 hoặc COM, và do đó cần bắt đầu bằng dấu gạch dưới, đặt trường hoặc biến trong một lớp NativeMethods đặc biệt. Một lớp NativeMethod là bất kỳ lớp nào có chứa một tên kết thúc bằng NativeMethods và được dự định là một trình giữ chỗ cho các trình bao bọc Win32 hoặc COM. StyleCop sẽ bỏ qua vi phạm này nếu mục được đặt trong lớp NativeMethods.

Một mô tả quy tắc khác chỉ ra rằng thực tiễn ưa thích ngoài việc trên là bắt đầu các trường riêng bằng chữ in thường và trường công khai bằng chữ in hoa.

Chỉnh sửa: Theo dõi, trang dự án của StyleCop được đặt tại đây: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Đọc qua tệp trợ giúp cung cấp nhiều thông tin chi tiết về lý do tại sao họ đề xuất các quy tắc phong cách khác nhau.

Vì chúng ta đang nói về một lĩnh vực riêng tư, nó không ảnh hưởng đến người dùng của lớp bạn.

Nhưng tôi khuyên bạn nên sử dụng dấu gạch dưới cho trường riêng, vì nó có thể giúp mã dễ hiểu hơn, ví dụ:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

Trong nhóm của chúng tôi, chúng tôi luôn sử dụng tiền tố gạch dưới cho các trường riêng. Do đó, khi đọc một số mã, tôi có thể rất dễ dàng xác định các trường riêng tư và phân biệt chúng với các đối số và đối số. Theo một cách nào đó, gạch dưới có thể được xem như là một phiên bản tốc ký của "cái này".

Sau khi làm việc trong một môi trường có các quy tắc phong cách rất cụ thể và rất vô nghĩa kể từ đó, tôi tiếp tục tạo ra phong cách của riêng mình. Đây là một loại mà tôi đã lật qua lật lại rất nhiều. Cuối cùng tôi đã quyết định các trường riêng sẽ luôn là _field, các biến cục bộ sẽ không bao giờ có _ và sẽ là chữ thường, tên biến cho các điều khiển sẽ lỏng lẻo theo ký hiệu Hungary và các tham số thường sẽ là camelCase.

Tôi ghê tởm this.từ khóa nó chỉ thêm quá nhiều tiếng ồn mã theo ý kiến ​​của tôi. Tôi yêu Resharper loại bỏ dư thừa này. từ khóa.

Cập nhật 6 năm: Tôi đã phân tích các phần bên trong Dictionary<TKey,T>để sử dụng cụ thể quyền truy cập đồng thời và đọc sai một trường riêng thành một biến cục bộ. Các trường riêng chắc chắn không nên là quy ước đặt tên giống như các biến cục bộ. Nếu có một dấu gạch dưới, nó sẽ cực kỳ rõ ràng.

Tôi thích dấu gạch dưới, vì sau đó tôi có thể sử dụng tên chữ thường làm tham số phương thức như thế này:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Tôi vẫn thực sự thích sử dụng dấu gạch dưới trước các trường riêng vì lý do Martin đã đề cập và cũng vì các trường riêng sau đó sẽ sắp xếp cùng nhau trong IntelliSense. Điều này là bất chấp sự xấu xa của các ký hiệu tiền tố Hungary nói chung.

Tuy nhiên, trong thời gian gần đây tôi thấy rằng việc sử dụng tiền tố gạch dưới cho các thành viên tư nhân là điều không được chấp nhận, mặc dù tôi không chắc tại sao. Có lẽ ai khác biết? Có phải nó chỉ là nguyên tắc tiền tố? Hoặc có một cái gì đó liên quan đến việc xáo trộn tên các loại chung có được dấu gạch dưới trong chúng trong các cụm lắp ráp hoặc một cái gì đó?

Đề xuất Style Cop hay không, đào sâu vào .NET Framework cho thấy rất nhiều cách sử dụng "_" cho các biến thành viên. Dù những người tạo ra Style Cop khuyên dùng gì, đó không phải là điều mà phần lớn nhân viên MS đang sử dụng. :) Vì vậy, tôi sẽ gắn bó với gạch dưới. Bởi vì cá nhân tôi đã ít mắc lỗi hơn khi sử dụng dấu gạch dưới, sau đó là điều này (ví dụ: sử dụng varName = varName thay vì this.varName = varName, nó thực sự bị mắc kẹt trong tôi)

Tôi nghĩ rằng các trường cấp độ lớn là một sai lầm trong thiết kế ngôn ngữ. Tôi sẽ thích nó hơn nếu các thuộc tính của C # có phạm vi cục bộ của riêng chúng:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Điều đó sẽ làm cho nó có thể ngừng sử dụng các trường hoàn toàn.

Lần duy nhất tôi từng tiền tố một trường riêng có dấu gạch dưới là khi một thuộc tính yêu cầu một trường sao lưu riêng. Đó cũng là lần duy nhất tôi sử dụng các lĩnh vực tư nhân. (Và vì tôi không bao giờ sử dụng các trường được bảo vệ, nội bộ hoặc công khai, đó là lần duy nhất tôi sử dụng thời gian của các trường.) Theo như tôi quan tâm, nếu một biến cần có phạm vi lớp, thì đó là thuộc tính của lớp.

Ký hiệu _fieldName cho các trường riêng rất dễ bị hỏng . Sử dụng cái này." ký hiệu là không thể phá vỡ. Làm thế nào bạn sẽ phá vỡ ký hiệu _? Quan sát:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Có bạn đi, tôi chỉ vi phạm quy ước đặt tên của bạn nhưng nó biên dịch. Tôi muốn có một quy ước đặt tên đó là a) không phải là Lynn và b) rõ ràng. Tôi ủng hộ việc loại bỏ tên Hungary và điều này đủ điều kiện theo một cách. Thay vì loại đối tượng ở phía trước tên biến, bạn có cấp truy cập của nó.

Đối chiếu điều này với Ruby trong đó tên của biến @my_numberliên kết tên vào phạm vi và không thể phá vỡ.

chỉnh sửa: Câu trả lời này đã đi tiêu cực. Tôi không quan tâm, nó ở lại.

Khi bạn muốn lắp ráp của bạn tuân thủ CLS, bạn có thể sử dụng thuộc tính CLSCompliant trong tệp lắp ráp của bạn. Trình biên dịch sau đó sẽ khiếu nại khi mã của bạn chứa những thứ không tuân thủ cls.

Sau đó, khi bạn có 2 thuộc tính chỉ khác nhau trong trường hợp, trình biên dịch sẽ báo lỗi. Mặt khác, khi bạn có một lĩnh vực riêng tư và một tài sản công cộng trong cùng một lớp, sẽ không có vấn đề gì.

(Nhưng, tôi cũng luôn đặt tiền tố cho các thành viên riêng của mình bằng dấu gạch dưới. Nó cũng giúp tôi làm rõ khi tôi đọc mã của mình rằng một biến nhất định là trường thành viên).

Tôi thích sử dụng dấu gạch dưới trước các lĩnh vực riêng tư của tôi vì hai lý do. Một đã được đề cập, các trường nổi bật từ các thuộc tính liên quan của chúng trong mã và trong Intellisense. Lý do thứ hai là tôi có thể sử dụng các quy ước đặt tên tương tự cho dù tôi đang mã hóa bằng VB hay C #.

Không có ý nghĩa gì. Khi mã của bạn được biên dịch, tất cả những gì quan trọng đối với trình biên dịch là không gian tên và thuộc tính của trường / thuộc tính. Một dấu gạch dưới cũng quan trọng như bất kỳ ký tự nào khác khi đặt tên định danh. Bí quyết thực sự là sử dụng một quy ước mà bạn và những người xung quanh sẽ hiểu.