2008-08-11 76 views
21

Có quy ước chính thức nào để đặt tên các trường riêng tư trong VB.NET không? Ví dụ: nếu tôi có thuộc tính có tên 'Foo', tôi thường gọi trường riêng '_Foo'. Điều này dường như được tán thành trong Offical Guidelines:Quy ước đặt tên cho các trường riêng VB.NET

"Không sử dụng tiền tố cho tên trường. Ví dụ: không sử dụng g_ hoặc s_ để phân biệt các trường tĩnh và không tĩnh".

Trong C#, bạn có thể gọi trường riêng 'foo', thuộc tính 'Foo' và tham chiếu đến trường riêng tư dưới dạng 'this.foo' trong hàm tạo. Như VB.NET là trường hợp không nhạy cảm, bạn không thể làm điều này - bất cứ đề nghị?

+3

Những nguyên tắc chính thức này là dành cho việc phát triển thư viện lớp học và chỉ áp dụng cho các phần tử ** công khai ** chứ không phải các yếu tố riêng tư. – MarkJ

Trả lời

20

Tôi vẫn sử dụng tiền tố _ trong VB cho các trường riêng tư, vì vậy tôi sẽ có _foo là trường riêng và Foo làm thuộc tính. Tôi làm điều này cho C# là tốt và khá nhiều bất kỳ mã tôi viết. Nói chung tôi sẽ không bị cuốn vào "cách đúng đắn để làm điều đó" bởi vì không thực sự là một cách "đúng" (altho có một số cách rất xấu) nhưng thay vì quan tâm đến việc làm nó một cách nhất quán.

Vào cuối ngày, nhất quán sẽ làm cho mã của bạn dễ đọc hơn và dễ bảo trì hơn so với sử dụng bất kỳ quy ước "đúng" nào.

3

Nguyên tắc chính thức chỉ là - nguyên tắc. Bạn luôn có thể đi xung quanh họ. Điều đó đang được nói, chúng tôi thường tiền tố các trường có dấu gạch dưới trong cả hai C# và VB.NET. Quy ước này khá phổ biến (và rõ ràng là Nguyên tắc chính thức bị bỏ qua).

Private lĩnh vực sau đó có thể được tham chiếu mà không có "tôi" từ khóa ("này" từ khóa là dành cho C# :)

2

Tôi không nghĩ rằng có một quy ước đặt tên chính thức, nhưng tôi đã nhìn thấy rằng Microsoft sử dụng m_ trong Microsoft.VisualBasic dll (thông qua phản xạ).

0

Tôi đồng ý với @lomaxx, điều quan trọng là nhất quán trong toàn đội hơn là có quy ước phải.

Tuy nhiên, sau đây là một số nơi tốt để lấy ý tưởng và hướng dẫn cho công ước mã hóa:

  1. Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# phát triển bởi Francesco Balena là một cuốn sách tuyệt vời mà đề cập đến nhiều vấn đề này.
  2. IDesign Coding Standards (đối với C# và cho WCF)
  3. .NET Framework Source Code (trong VS2008)
0

Tôi thích sử dụng tiền tố gạch cho các lĩnh vực tư nhân. Tôi sử dụng chữ thường đầu tiên cho các tham số phương thức. Tôi làm theo hướng dẫn của việc có các tham số camelcase thường cho các phương thức, mà tôi coi là quan trọng hơn việc đặt tên các trường riêng vì nó là một phần của API cho lớp đó. . ví dụ.

Public Class Class1 

    Private _foo As String 
    Public Property Foo() As String 
     Get 
      Return _foo 
     End Get 
     Set(ByVal value As String) 
      _foo = value 
     End Set 
    End Property 

    Public Sub New(ByVal foo As String) 
     _foo = foo 
    End Sub 

End Class 

Sử dụng mẫu này, bạn sẽ không có bất kỳ xung đột tên nào với trường riêng và tham số hàm tạo trong C# hoặc VB.NET.

2

tôi vẫn sử dụng tiền tố _ trong VB cho lĩnh vực tư nhân, vì vậy tôi sẽ có _foo như lĩnh vực tư nhân và Foo như tài sản. Tôi làm điều này cho C# là tốt và khá nhiều bất kỳ mã nào tôi viết. Nói chung, tôi sẽ không bị bắt quá trong "cách phù hợp để làm điều đó" vì không thực sự là cách "đúng" (có một số cách rất xấu ) nhưng cần phải quan tâm làm điều đó một cách nhất quán.

Tôi chưa tìm thấy điều gì tốt hơn "_" để làm rõ và nhất quán. Nhược điểm bao gồm:

  • Not CLS compliant
  • Có xu hướng để có được mất khi VB vẽ các đường ngang qua IDE của tôi

tôi nhận được xung quanh các dòng bằng cách chuyển những tắt trong trình soạn thảo, và cố gắng không suy nghĩ quá nhiều về sự tuân thủ CLS.

+6

Việc tuân thủ CLS không quan tâm đến các tên trường riêng tư. –

3

Nguyên tắc thiết kế mà bạn đã liên kết cụ thể cho biết rằng chúng chỉ áp dụng cho các trường công cộng và được bảo vệ tĩnh. Các hướng dẫn thiết kế chủ yếu tập trung vào việc thiết kế các API công cộng; những gì bạn làm với các thành viên riêng tư của bạn là tùy thuộc vào bạn. Tôi không tích cực nhưng tôi khá tự tin rằng các thành viên tư nhân không được xem xét khi trình biên dịch kiểm tra sự tuân thủ CLS, bởi vì chỉ có các thành viên công cộng/được bảo vệ mới tham gia chơi (ý tưởng là, "Điều gì sẽ xảy ra nếu ai đó sử dụng ngôn ngữ không cho phép ký tự _ cố gắng sử dụng thư viện của bạn? "Nếu các thành viên là riêng tư, câu trả lời là" Không có gì, người dùng không phải sử dụng các thành viên này ". Nhưng nếu các thành viên công khai bạn gặp rắc rối.)

Điều đó nói rằng, tôi sẽ thêm vào buồng echo và chỉ ra rằng bất cứ điều gì bạn làm, điều quan trọng là phải nhất quán. Người sử dụng lao động của tôi yêu cầu rằng các lĩnh vực tư nhân trong cả C# và VB đều có tiền tố _, và bởi vì tất cả chúng ta tuân theo quy ước này, nó dễ sử dụng mã được viết bởi người khác.

0

Tôi đồng ý quan trọng nhất không phải là phong cách nào được sử dụng nhưng nó nhất quán.

Với những gì đã nói, MS/NET phong cách mới cho lĩnh vực tư nhân có xu hướng được _fooVar (gạch dưới theo sau là một tên camelCased)

5

Đó là sở thích cá nhân, mặc dù có sự ủng hộ rộng rãi để có một số phân biệt. Ngay cả trong C# tôi không nghĩ rằng có một quy ước được sử dụng rộng rãi.

Jeff Prosise nói

Như một vấn đề của sở thích cá nhân tôi lĩnh vực tư nhân thường tiền tố với một dấu gạch dưới [C#] ... ước này được sử dụng khá nhiều trong khuôn khổ NET nhưng nó không được sử dụng khắp.

Từ. NET Framework Design Guidelines 2nd Edition trang 73.

Jeffrey Richter nói

tôi làm cho tất cả các lĩnh vực của tôi tin và tôi tiền tố instance fields của tôi với "m_" và các lĩnh vực tĩnh của tôi với "s_" [C#]

Từ. NET Framework Design Guidelines Trang 2nd Edition 47. Anthony Moore (BCL team) cũng cho rằng việc sử dụng "m_" và "s_" đáng xem xét, trang 48.

2

Trong VB.NET 4.0, hầu hết các bạn có thể biết bạn không cần phải viết một cách rõ ràng getter và setter cho tờ khai tài sản của bạn như sau:

Public Property Foo As String 
Public Property Foo2 As String 

VB tự động tạo ra các biến thành viên private gọi _Foo và _Foo2. Có vẻ như Microsoft và nhóm VS đã thông qua quy ước _, vì vậy tôi không thấy có vấn đề gì với nó.

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