Là tiền tố loại và phạm vi có giá trị quy ước đặt tên?

Gần đây, bắt đầu công việc đầu tiên của mình là một nhà phát triển phần mềm, tôi đã có một chút bối rối khi được nói rằng tôi không phải tuân theo bất kỳ quy ước đặt tên nào trong mã của mình. Mã được viết bởi các nhóm làm việc trên các dự án khác, lớn hơn tuân theo các quy ước đặt tên, nhưng vì tôi được đưa vào để viết một ứng dụng mới, độc lập, cảm giác là nó không đặc biệt quan trọng. Đó là lo lắng cuối cùng của tôi, vì vậy tôi chỉ cần tham gia hội nghị hiện có và chạy theo nó.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Nhưng nó có thực sự đáng giá? Tôi thấy thật khó để đánh giá hiệu ứng ròng mà theo loại quy ước đặt tên này có thể hiểu và phát hiện ra các lỗi, nhưng, về mặt trực quan , nó trông có vẻ xấu xí. Thêm vào đó, có tất cả các lớp và tệp trong dự án được gọi là cS Something có vẻ khá đẹp.

Tôi không ảo tưởng rằng đó là một vấn đề lớn từ xa khi so sánh với những thứ tạo ra sự khác biệt rõ ràng, như các thuật toán và kiến ​​trúc mà bạn sử dụng. Nhưng bất kỳ quy ước nào ảnh hưởng đến mọi dòng mã mà tôi viết dường như đều có giá trị.

Bạn tìm thấy quy ước đặt tên thanh lịch và hiệu quả nhất là gì, nếu cần sử dụng tất cả? Nó biểu thị loại và / hoặc phạm vi?

Joel Spolsky đã viết một bài báo về lý do tại sao ký hiệu Hungary tồn tại và mục đích của nó có thể giúp trả lời câu hỏi của bạn.

Các tiền tố như tbl cho bảng cơ sở dữ liệu, int cho một số nguyên, v.v ... thường không hữu ích - việc tìm ra những gì từ ngữ cảnh hoặc từ các công cụ phát triển của bạn trong những trường hợp đó là không quan trọng. Một cái gì đó giống như imp cho các phép đo đế quốc và được đáp ứng cho số liệu có ý nghĩa hơn nhiều bởi vì nếu không, bạn chỉ có thể thấy rằng chúng là các số dấu phẩy động.

area = width * height

trông hoàn toàn ổn trong khi

impArea = metWidth * impHeight

cho bạn thấy thẳng rằng có gì đó không ổn

Cá nhân tôi chỉ sử dụng tên biến mô tả. $ number_of_items rõ ràng là một số nguyên. $ input_file_handle, $ is_active và $ rypt_password có các loại rõ ràng cả về loại dữ liệu ngôn ngữ và loại ngữ nghĩa.

Những gì bạn đang mô tả được gọi là ký hiệu Hungary . Nó đã từng được coi là thực hành tốt nhất, nhưng nói chung là nhăn mặt bây giờ.

Bài viết Wikipedia chứa một phần về ưu và nhược điểm của nó.

Vâng, tiền tố có thể hữu ích, nhưng tôi có một vài gợi ý:

Nếu toàn bộ nhóm của bạn đang sử dụng các quy ước tương tự, chúng sẽ trở nên hữu ích hơn nhiều. Sử dụng chúng một mình là ít hữu ích.

Trong các ngôn ngữ được gõ tĩnh, không chỉ sao chép loại biến. Ví dụ: "bSubscribeed" là một tên xấu cho biến boolean trong C # hoặc Java, vì IDE của bạn đã biết nó là loại gì. Mặt khác, trong C, thiếu loại boolean, đây sẽ là thông tin hữu ích.

Trong C # và Java, bạn có thể xem xét một tiền tố để chỉ ra rằng một đối tượng có thể là null. Hoặc là một chuỗi đã được thoát html. Hoặc nó đại diện cho một biểu thức chính quy, hoặc một câu lệnh sql. Hoặc là một mảng đã được sắp xếp. Sử dụng trí tưởng tượng của bạn.

Về cơ bản, đó là một câu hỏi về việc tự hỏi bạn muốn một tên biến để nói với bạn điều gì và điều đó phụ thuộc rất nhiều vào tên miền và ngôn ngữ bạn đang làm việc.

Có một vài "phong cách" khác nhau về quy ước đặt tên ngoài kia, và hầu hết chúng đều có một số giá trị trong việc làm cho mã trở nên dễ hiểu.

FAR quan trọng hơn là gì: sử dụng tên mô tả cho các biến và hàm. Trong ví dụ của bạn với "tổng", "trọng lượng" và "giá trị", bạn có thể muốn đặt tên có ý nghĩa hơn: "TotalCost", "lumberweight", "lumberValuePerOunce" (Tôi đang đưa ra một số giả định ở đây)

Tôi thấy các quy ước như sắp xếp trước các tên biến với một ký tự biểu thị loại sẽ khá mất tập trung trong hầu hết các ngôn ngữ hiện đại.

Hầu hết các nhà phát triển .NET tuân theo Nguyên tắc thiết kế của Microsoft ( http://msdn.microsoft.com/en-us/l Library / ms229042.aspx ), khá giống với Java (điểm khác biệt chính là Microsoft ưu tiên Pascal Case cho tên thành viên, trong khi Java ủng hộ trường hợp lạc đà).

Ngoài ra, tôi muốn nói rằng mẫu mã của bạn ít được đọc hơn do có thêm tiếng ồn.

Tôi thấy rằng, đối với hầu hết các phần, hướng dẫn về phong cách mã hóa của Google là khá tốt. Vì bạn được bảo rằng bạn có thể sử dụng bất kỳ phong cách nào bạn thích, tôi nghĩ bạn nên bắt đầu bằng cách xem qua, và chọn và chọn từ nó.

Tiền tố tên biến với các loại dữ liệu (đặc biệt là các loại dữ liệu nguyên thủy) làm tăng nhiễu hình ảnh, cũng như nguy cơ một thay đổi nhỏ khác sẽ trở thành một sự đổi tên lớn.

Điểm đầu tiên, "intStudentCount" có thực sự rõ ràng hơn ví dụ "numberOfStudents" không? Sẽ không "billingLineItems" ít nhất là thông tin như "aobjItems". (Kiểu dữ liệu phải là về ý nghĩa của dữ liệu trong miền sự cố, không phải là biểu diễn ở mức độ thấp.)

Đối với điểm thứ hai, điều gì xảy ra khi ví dụ một lựa chọn int sớm được thay thế bằng dài hoặc gấp đôi? Thậm chí tệ hơn, điều gì xảy ra khi một lớp cụ thể được tái cấu trúc thành một giao diện với nhiều lớp thực hiện? Bất kỳ thực hành nào làm tăng gánh nặng của các kịch bản bảo trì thực tế dường như là nghi vấn đối với tôi.

Nó cũng có thể phụ thuộc vào lý do tại sao bạn đặt tiền tố tên, trái ngược với những gì bạn đặt trước nó.

Ví dụ, tôi có xu hướng sử dụng tiền tố 1-2 chữ cái cho tên của các điều khiển trên một biểu mẫu. Không phải vì tôi không biết rằng trình biên dịch sẽ dễ dàng tìm đúng lớp cho nút (ví dụ), nhưng tôi có xu hướng thiết kế các biểu mẫu lớn trước, sau đó viết hầu hết mã sau đó.

Có tiền tố bt cho các nút giúp bạn dễ dàng tìm thấy nút bên phải sau đó, thay vì có nhiều tên bị xáo trộn với nhau.

Mặc dù vậy, tôi không sử dụng tiền tố để đặt tên biến, không phải loại (dù sao nó thường không hữu ích), cũng không phải ý nghĩa, bối cảnh hoặc đơn vị (vốn là ý tưởng ban đầu đằng sau Ký hiệu Hungary).

Theo quan điểm của tôi, nó phụ thuộc vào ngôn ngữ và quy mô của dự án. Tôi chưa bao giờ thực sự đi xa đến mức sử dụng tiền tố loại trên tất cả các biến của mình, nhưng bạn muốn đặt tên cho chúng một cách rõ ràng.

Trong một ngôn ngữ được gõ tĩnh, giống như ngôn ngữ bạn đang sử dụng, tôi càng cảm thấy thoải mái hơn với hệ thống loại, Ký hiệu Hungary ít quan trọng hơn. Vì vậy, trong Java hoặc C # và đặc biệt là trong Haskell, tôi thậm chí sẽ không nghĩ đến việc thêm các tiền tố đó, bởi vì các công cụ của bạn có thể cho bạn biết loại của bất kỳ biểu thức đã cho nào và sẽ bắt được hầu hết các lỗi do hiểu nhầm một loại.

Tiền tố thường có ý nghĩa đối với các đối tượng, ví dụ ở dạng bạn có thể có 20 hộp văn bản gọi tất cả đều tbSomethingcó ý nghĩa.

Tuy nhiên, chủ yếu tôi không nghĩ nó đáng giá, đặc biệt là đối với các loại giá trị.

Ví dụ: giả sử bạn có:

short shortValue = 0;
//stuff happens

Nhiều tháng sau bạn thấy bạn cần thay đổi nó - một thời gian ngắn không đủ lớn. Bây giờ bạn có:

int shortValue = 0;
//stuff happens

Trừ khi bây giờ bạn cũng thay đổi tên của biến (có nhiều rủi ro vi phạm mã hơn là thay đổi loại trong trường hợp này), bây giờ bạn có mã khó hiểu.

Tốt hơn hết là bạn nên có một cái tên mô tả những gì nó chứa:

int loopCounter = 0;
//stuff happens

Nếu sau này cần phải thay đổi lâu dài: không vấn đề gì.

Có thể có nhiều tranh luận hơn cho các quy ước này trong các ngôn ngữ được gõ động hoặc những ngôn ngữ không có IDE.

Tôi luôn có xu hướng sử dụng từ viết tắt 2 đến 4 ký tự cho loại đứng trước biến đó. Đôi khi nó có vẻ tẻ nhạt, nhưng khi bạn làm việc với các kiểu dữ liệu hoặc tình huống phức tạp, nó sẽ trở nên có lợi. Tôi nghĩ rằng nó rơi vào loại trường hợp lạc đà thấp hơn.

Nhìn vào ví dụ của bạn ở trên, nó sẽ được trang bị lại một chút:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Mảng luôn có một phía trước của loại để chỉ định mảng. Điều này cũng cho phép tôi nhóm các trường hợp biến tương tự lại với nhau. Chẳng hạn, tôi có thể sử dụng ...

taStore.Fill(dtStore);

... cho biết Store TableAd CHƯƠNG của tôi đang điền vào Store DataTable.

Tôi đã luôn cố gắng tuân thủ nguyên tắc cơ bản rằng các tiền tố và / hoặc hậu tố chỉ nên được chèn khi nó làm cho mã dễ đọc hơn (như tiếng Anh đơn giản).

Càng ít khó hiểu, càng tốt ...

Tại sao có một phương pháp như thế này:

public boolean connect( String h, int p );

Khi bạn có thể có một cái gì đó như thế này:

public boolean connect( String hostName, int port );

Hơn nữa, các IDE ngày nay thực sự có công cụ mạnh mẽ để tái cấu trúc các biến (đặc biệt là Java), tên phương thức, lớp, v.v ... Ý tưởng để nói thông tin tối đa với số lượng ký tự ít nhất chỉ là lỗi thời.