2009-04-20 46 views
27

Trước khi sử dụng C#, C++ là ngôn ngữ lập trình chính của tôi. Và ký hiệu Hungary sâu thẳm trong trái tim tôi.Ký hiệu Hungary trong C#

Tôi đã thực hiện một số dự án nhỏ trong C# mà không cần đọc một cuốn sách C# hoặc các hướng dẫn khác về ngôn ngữ. Trong những dự án nhỏ C# tôi đã sử dụng một cái gì đó giống như

private string m_strExePath; 

Cho đến khi tôi đọc một cái gì đó từ SO mà nói:

Không sử dụng ký hiệu Hungary.

Vậy tại sao? Tôi có phải là người duy nhất có m_strExePath hoặc m_iNumber trong mã C# của tôi không?

+0

Trùng lặp? http: // stackoverflow.com/questions/659552/why-should-or-shouldnt-i-prefix-fields-with-m-in-c –

Trả lời

21

Không, bạn không phải là người duy nhất làm điều đó. Nó thường chỉ chấp nhận rằng ký hiệu Hungary không phải là cách tốt nhất để đặt tên cho mọi thứ trong C# (IDE xử lý rất nhiều o các vấn đề mà ký hiệu Hungary đã cố gắng giải quyết).

+1

IDE xử lý bất kỳ vấn đề nào mà ký hiệu thực sự của Hungary? Tôi không nói về các loại Net. Ở đây, xem bài viết của Joel trong câu trả lời hàng đầu. –

1

Nếu ký pháp Hungary sâu trong lòng bạn và nhóm của bạn và trái tim của công ty bạn, bằng mọi cách, hãy sử dụng nó. Nó không còn được coi là một thực hành tốt nhất như xa như tôi có thể đọc từ các blog và sách.

1

Nếu bạn giữ con trỏ trên biến trong VS nó sẽ cho bạn biết loại biến đó là gì, vì vậy không có lý do gì để đi với các tên biến bí ẩn này, đặc biệt là những người đến từ các ngôn ngữ khác có thể cần phải duy trì mã và nó sẽ là một trở ngại để dễ đọc.

29

Bạn không phải là người duy nhất, nhưng tôi cho rằng điều đó tương đối không phổ biến. Cá nhân tôi không phải là một fan của ký hiệu Hungary, ít nhất là không theo nghĩa đơn giản mà chỉ cần giữ lại các thông tin kiểu mà đã có trong tờ khai. (Người hâm mộ ký hiệu "đúng" Hungary sẽ giải thích sự khác biệt - nó không bao giờ làm phiền tôi nhiều, nhưng tôi có thể thấy điểm của họ. Nếu bạn sử dụng tiền tố chung cho đơn vị chiều dài so với đơn vị trọng lượng, bạn sẽ không vô tình gán một biến chiều dài với một giá trị trọng số, mặc dù cả hai có thể là số nguyên.)

Tuy nhiên, đối với các thành viên riêng, bạn có thể thực hiện những gì bạn muốn - đồng ý với nhóm của bạn quy ước đặt tên là gì. Điểm quan trọng là nếu bạn muốn API của bạn để phù hợp với phần còn lại của .NET, không sử dụng ký pháp Hungary trong các thành viên công khai của bạn (bao gồm các tham số).

+0

@Jon: họ nói việc sử dụng hình ảnh khiêu dâm không phải là một cách thực hành tốt nhưng có vấn đề thực sự nào không? nó gây ra bất kỳ tác hại cụ thể (effeciency/compiler vấn đề gì)? persoanlly tôi không sử dụng nó trong lớp học của tôi, nhưng đối với các mục trực quan như textBox, nhãn vv tôi sử dụng txt và lbl của tương ứng. Vui lòng nhận xét. –

+1

Không, tên biến không thay đổi hiệu quả hoặc biên dịch lần vv Chúng ảnh hưởng đến khả năng đọc nhiều hơn bất kỳ thứ gì khác. (Ồ, và các thành viên công cộng khác nhau theo từng trường hợp sẽ giới hạn khả năng sử dụng loại từ các ngôn ngữ không phân biệt dạng chữ như VB.) –

28

Khi thiết kế giao diện người dùng, tôi thấy nó rất hữu ích để duy trì ký pháp Hungary. Các mục như hộp văn bản, nhãn và danh sách thả xuống dễ dàng hơn nhiều để hiểu nhanh và thường bạn nhận được tên kiểm soát lặp lại:

lblTitle = Label 
txtTitle = TextBox 
ddlTitle = DropDownList 

Để tôi dễ đọc và phân tích cú pháp hơn. Nếu không, ký hiệu Hungary không phù hợp vì những tiến bộ trong IDE, cụ thể là Visual Studio.

Ngoài ra, Joel trên Phần mềm có một bài viết tuyệt vời liên quan đến ký hiệu Hungari có tiêu đề: Making Wrong Code Look Wrong, làm cho một số đối số tốt cho ký hiệu Hungary.

+12

Tôi không đồng ý. Tôi nghĩ rằng nó thậm chí còn tồi tệ hơn trong trường hợp này, đặc biệt là khi bạn nhận được vào điều khiển với tên dài hơn hoặc 3 chữ viết tắt xung đột với chữ viết tắt 3 chữ của điều khiển khác. Thay vào đó, chúng tôi sử dụng TitleLabel hoặc TitleTextBox hoặc TitleDropDown, v.v. – John

+2

@ John: Tôi hoàn toàn đồng ý. Không có giới hạn ký tự đối với chúng tôi và chúng tôi sẽ làm cho các biến trở nên dễ đọc và dễ đọc. –

+3

@Jeff & John - Chỉ vì chúng tôi không có giới hạn ký tự không có nghĩa là nó nên được sử dụng. Các biến ngắn gọn hơn> Các biến biểu cảm dài hơn –

5

trừ khi bạn đang sử dụng một trình soạn thảo văn bản chứ không phải là VS IDE có rất ít giá trị cho ký hiệu hungarian và nó impeeds chứ không phải là cải thiện khả năng đọc

6

Một nhược điểm của ký hiệu Hungarian là các nhà phát triển thường xuyên thay đổi kiểu của các biến trong thời kỳ đầu mã hóa, yêu cầu tên của biến cũng thay đổi.

+3

Đồng ý, nó thêm gánh nặng bảo trì vào một codebase. –

2

duy nhất hai lĩnh vực mà tôi đang nhìn thấy bất kỳ hình thức ký hiệu Hungarian là: các biến thành viên

  • Class, với một dấu gạch dưới hàng đầu (ví dụ _someVar)
  • WinForms và tên WebForms điều khiển (btn cho Button, lbl cho Nhãn v.v.)

Dấu gạch dưới hàng đầu trên các biến thành viên có vẻ như ở đây để ở lại với chúng ta lâu hơn, nhưng tôi mong thấy sự phổ biến của Hun garian trên kiểm soát tên để wane.

+0

Tôi tránh * mọi dấu gạch dưới hàng đầu để tránh chạy các yêu cầu đặt tên của C++. Có, tôi biết đây là C# ... –

47

Joel Spolsky có thực sự tốt article về chủ đề này. Tóm tắt nhanh là có hai loại ký hiệu Hungary được sử dụng trong thực tế.

Đầu tiên là "Hệ thống Hungary" nơi bạn chỉ định loại biến sử dụng tiền tố. Những thứ như "str" ​​cho chuỗi. Đây là thông tin gần như vô dụng, đặc biệt là kể từ khi IDE hiện đại sẽ cho bạn biết loại nào.

Thứ hai là "Ứng dụng Hungary", trong đó bạn chỉ định mục đích của biến có tiền tố. Ví dụ phổ biến nhất về điều này là sử dụng "m_" để chỉ các biến thành viên. Điều này có thể cực kỳ hữu ích khi được thực hiện đúng.

Đề xuất của tôi là tránh "Hệ thống Hungary" như bệnh dịch hạch nhưng chắc chắn sử dụng "Ứng dụng Hungary" ở nơi có ý nghĩa. Tôi đề nghị đọc bài viết của Joel. Đó là một chút dài quanh co nhưng giải thích nó tốt hơn nhiều so với tôi có thể.

Phần thú vị nhất của bài viết này là nhà phát minh gốc của ký hiệu Hungary, Charles Simonyi, đã tạo ra "Ứng dụng Hungary" nhưng bài báo của ông bị hiểu sai một cách kinh khủng và việc "Hệ thống Hungary" bị hủy bỏ.

+0

Chúng tôi đã thảo luận trước đây và tôi hoàn toàn có thể thấy điểm "Ứng dụng Hungary" nhưng tôi muốn chỉ ra rằng trong C++ điều này cũng không cần thiết, nếu bạn sử dụng kỹ thuật được mô tả trong cuốn sách của Scott Meyers "Hiệu quả C++", Mục 18, trang 78. –

+3

Tôi đã có Ấn bản thứ 2 và Mục 18 là "Phấn đấu cho các giao diện lớp hoàn chỉnh và tối thiểu" không liên quan đến điều này . –

+5

Tôi không thấy điểm trong Ứng dụng tiếng Hungari khi IDE có thể cho bạn biết nếu có gì đó là biến thành viên. –

10

Bạn chắc chắn không phải là người duy nhất, nhưng tôi hy vọng bạn là một phần của một xu hướng giảm :)

Vấn đề với ký hiệu Hungarian là nó đang cố gắng để thực hiện một hệ thống kiểu qua quy ước đặt tên. Điều này cực kỳ có vấn đề bởi vì nó là một hệ thống kiểu chỉ với sự xác minh của con người. Mọi người trong dự án đều phải đồng ý với cùng một bộ tiêu chuẩn, thực hiện đánh giá mã nghiêm ngặt và đảm bảo rằng tất cả các loại mới đều được gán tiền tố thích hợp và chính xác. Trong ngắn hạn, nó không thể đảm bảo tính nhất quán với một cơ sở mã đủ lớn. Tại thời điểm đó không có sự nhất quán tại sao bạn làm điều đó?

Ngoài ra, các công cụ không hỗ trợ ký hiệu Hungary. Điều đó có vẻ giống như một nhận xét ngu ngốc trên bề mặt nhưng xem xét tái cấu trúc chẳng hạn. Mỗi phép tái cấu trúc trong hệ thống quy ước đặt tên của Hungary phải đi kèm với việc đổi tên hàng loạt để đảm bảo rằng các tiền tố được duy trì. Đổi tên hàng loạt là dễ bị tất cả các loại lỗi tinh tế.

Thay vì sử dụng tên để triển khai hệ thống kiểu, chỉ cần dựa vào hệ thống kiểu. Nó có hỗ trợ xác minh và công cụ tự động. IDE mới hơn giúp bạn dễ dàng khám phá kiểu biến (intellisense, hover tips, etc ...) và thực sự loại bỏ mong muốn ban đầu cho ký hiệu Hungary.

13

Ký hiệu Hungary là một sai lầm khủng khiếp, trong bất kỳ ngôn ngữ nào. Bạn cũng không nên sử dụng nó trong C++. Đặt tên cho các biến của bạn để bạn biết chúng là gì. Không đặt tên cho chúng để sao chép thông tin kiểu mà IDE có thể cung cấp cho bạn dù sao, và có thể thay đổi (và thường là không liên quan anyway.Nếu bạn biết rằng một cái gì đó là một truy cập, sau đó nó không quan trọng cho dù đó là một int16, 32 hoặc 64. Bạn biết rằng nó hoạt động như một truy cập, và như vậy, bất kỳ hoạt động đó là hợp lệ trên một quầy nên hợp lệ. Đối số tương tự cho các tọa độ X/Y. Chúng là tọa độ. Nó không quan trọng nếu họ đang nổi hoặc tăng gấp đôi. Nó có thể có liên quan để biết liệu một giá trị có ở đơn vị trọng lượng, khoảng cách hoặc tốc độ không. Nó không quan trọng đó là một phao.).

Thực tế, ký hiệu Hungary chỉ xuất hiện như một sự hiểu lầm. Nhà phát minh đã dự định sử dụng nó để mô tả loại "khái niệm" của một biến (có phải là toạ độ, chỉ mục, bộ đếm, cửa sổ không?)

Và những người đọc mô tả của ông cho rằng " nhập "anh ấy có nghĩa là loại ngôn ngữ lập trình thực tế (int, float, zero-terminated string, char pointer)

Đó không bao giờ là ý định, và đó là một ý tưởng khủng khiếp. Nó sao chép thông tin mà IDE có thể cung cấp tốt hơn, và đó không phải là tất cả những gì có liên quan ở nơi đầu tiên, vì nó khuyến khích bạn lập trình ở mức trừu tượng thấp nhất có thể.

Vậy tại sao? Tôi có phải là người duy nhất có m_strExePath hoặc m_iNumber trong mã C# của tôi?

Không may là không. Hãy cho tôi biết, điều gì sẽ exePath là nếu nó không phải là một chuỗi? Tại sao tôi, với tư cách là người đọc mã của bạn, cần phải biết rằng đó là một chuỗi? Không đủ để biết rằng đó là con đường dẫn đến thực thi? m_iNumber chỉ được đặt tên kém. số nào là là số này? Nó là cái gì? Bạn vừa mới nói với tôi hai lần rằng đó là một con số, nhưng tôi vẫn không biết ý nghĩa của con số đó là gì.

+2

IDE có thể cung cấp loại, nhưng chỉ khi tôi lãng phí một giây thời gian của tôi lơ lửng trên tên biến :-) Tôi muốn có thể nhìn thấy nó trong nháy mắt ... Và để cung cấp một điểm đối với ví dụ của bạn: exePath cũng có thể là một đối tượng System.IO.FileInfo, một trình bao bọc cho một đường dẫn tệp cung cấp khả năng truy cập dễ dàng vào các hoạt động hệ thống tệp chung. Tôi thành thật không thấy sự tổn hại trong tiền tố tên biến. Tôi thấy rằng nó làm cho kiểm tra mã và gỡ lỗi dễ dàng hơn. –

+2

Bạn cần kiểu gì? Khi tôi lập trình, tôi muốn biết biến * đại diện cho * là gì, không phải loại đó là gì. Nếu 'exePath' của bạn thuộc kiểu' FileInfo', nó được đặt tên rất xấu, và sau đó ** rằng ** là vấn đề của bạn. Tên của biến cho biết rằng đó là một đường dẫn, không phải là tệp thực. Vì vậy, khi tôi sử dụng nó, tôi hy vọng nó hoạt động như một tên đường dẫn, và không giống như một tập tin. – jalf

0

Trong ngôn ngữ như C# nơi nhiều hạn chế về độ dài tên biến không tồn tại một lần bằng các ngôn ngữ như C và C++ và nơi IDE cung cấp hỗ trợ tuyệt vời để xác định loại biến, ký hiệu Hungary là thừa .

Mã phải tự giải thích nên các tên như m_szName có thể được thay thế bằng this.name. Và m_lblName có thể là nameLabel, vv Điều quan trọng là nhất quán và tạo mã dễ đọc và duy trì - đây là mục tiêu của bất kỳ quy ước đặt tên nào, do đó bạn nên luôn quyết định bạn sử dụng quy ước nào dựa trên điều này. Tôi cảm thấy rằng ký hiệu Hungary không phải là dễ đọc nhất hoặc được duy trì nhiều nhất vì nó có thể quá ngắn, đòi hỏi một số kiến ​​thức nhất định về tiền tố và không phải là một phần của ngôn ngữ và do đó khó thực thi và khó phát hiện khi tên không còn khớp với loại cơ bản. Thay vào đó, tôi muốn thay thế ứng dụng Hungary (tiền tố như m_) bằng cách tham chiếu this cho các thành viên, tham chiếu tên lớp cho biến tĩnh và không có tiền tố cho biến cục bộ. Và thay vì System Hungarian (bao gồm kiểu biến trong tên biến), tôi thích mô tả biến là gì cho chẳng hạn như nameLabel, nameTextBox, count và databaseReference.

1

Ký hiệu hungarian nhất mô tả biến là gì (con trỏ, hoặc con trỏ tới con trỏ, hoặc nội dung của con trỏ, v.v.) và điều mà nó trỏ đến là (chuỗi v.v.).

Tôi đã tìm thấy rất ít sử dụng cho con trỏ trong C#, đặc biệt là khi không có cuộc gọi không được quản lý/pinvoke. Ngoài ra, không có tùy chọn để sử dụng void * vì vậy không có nhu cầu cho hungarian để mô tả nó.

Chỉ còn lại từ tiếng Hungari mà tôi (và hầu hết những người khác trong vùng đất C#) sử dụng, là đặt trước các trường riêng tư với _, như trong _customers;

+1

Bằng cách đó bạn biết ngay nếu biến là biến cục bộ hoặc biến thể và hữu ích kết hợp với nguyên nhân intellisense tất cả các trường riêng được hiển thị trên cùng nhau và bạn có thể tìm thấy bất kỳ trường mẫu nào chỉ bằng cách nhập _ – sam

5

Giá trị thực trong ký hiệu tiếng Hung-ga-ri có từ trở lại lập trình C và bản chất con trỏ được đánh máy yếu. Về cơ bản, trở lại trong ngày cách dễ nhất để theo dõi các loại là sử dụng Hungary.

Trong các ngôn ngữ như C# hệ thống loại cho bạn biết tất cả những gì bạn cần biết và IDE trình bày điều này cho bạn theo cách rất thân thiện với người dùng, vì vậy không cần sử dụng tiếng Hungari.

Vì lý do chính đáng để không sử dụng, cũng có một số ít. FIrstly, trong C# và cho rằng vấn đề C + + và nhiều langby khác bạn thường tạo ra các loại của riêng bạn, vì vậy những gì sẽ là người Hungary cho một loại "MyAccountObject"? Thậm chí nếu bạn có thể quyết định ký hiệu Hungary hợp lý, nó vẫn làm cho tên biến thực tế hơi khó đọc hơn vì bạn phải bỏ qua "LPZCSTR" (hoặc bất kỳ thứ gì) ngay từ đầu. Quan trọng hơn là chi phí bảo trì mặc dù, nếu bạn bắt đầu với một Danh sách và thay đổi sang một loại bộ sưu tập khác (điều tôi dường như làm rất nhiều vào lúc này)? Sau đó, bạn cần phải đổi tên tất cả các biến sử dụng loại đó, tất cả đều không có lợi ích thực sự. Nếu bạn vừa sử dụng một cái tên phong nha để bắt đầu với bạn sẽ không phải lo lắng về điều này. Trong ví dụ của bạn, nếu bạn tạo hoặc sử dụng một số loại có ý nghĩa hơn để giữ đường dẫn (ví dụ: Đường dẫn), thì bạn cần thay đổi m_strExePath thành m_pathExePath, đây là một nỗi đau và trong trường hợp này không thực sự hữu ích.

0

Tại một số điểm, bạn đang có khả năng để có một tài sản

public string ExecutablePath { ... } 

(không phải là bạn nên cố gắng tránh các chữ viết tắt như "Exe" quá). Trong trường hợp đó, câu hỏi của bạn có thể sau đó được tranh luận nhiều thời gian như bạn có thể sử dụng C# 3.0 tự động tính

public string ExecutablePath { get; set; } 

bây giờ bạn không còn phải tìm ra một cái tên cho biến cửa hàng quay lại. Không có tên, không có câu hỏi/tranh luận về quy ước đặt tên.

Rõ ràng, các thuộc tính được tự động triển khai không phải lúc nào cũng phù hợp.

+0

Câu trả lời này không liên quan đến Ký hiệu Hungary.Nó thuộc về một câu hỏi hỏi "tôi có nên đặt tên thành viên riêng của tôi _executablePath hoặc m_executablePath hoặc executablePath?", Không phải là câu hỏi này. – Lucas

+0

cảnh báo typo-means-the-opposite: "LƯU Ý rằng bạn nên thử ...", – Lucas

+0

Sử dụng các thuộc tính tự động -> không (hoặc ít nhất là ít hơn) cần phải suy nghĩ về các quy ước đặt tên như vậy. –

0

Điều đó tùy thuộc.

Có phải đủ quan trọng để thêm mô tả loại dữ liệu trong tên biến/đối tượng trong phương pháp/lớp học của bạn không?

Hệ thống Notation Hungary> Apps Notation Hungary

Nếu bạn đang thiết kế trong ngôn ngữ thủ tục (ví dụ C) có nhiều biến toàn cầu hoặc/và API thấp mà những giao dịch với các kiểu dữ liệu chính xác và kích thước (ví dụ C <stdint.h> trong đó hơn 40 ký hiệu kiểu dữ liệu khác nhau được sử dụng để mô tả int), Hệ thống ký hiệu Hungary hữu ích hơn. Tuy nhiên, nhiều nhà lập trình hiện đại xem xét việc thêm thông tin kiểu trong tên biến rất phong phú vì nhiều IDE hiện đại có các công cụ rất tiện lợi (ví dụ: Outline của Eclipse, Symbol Navigator của Xcode, Visual AssistX của Visual Studio, v.v.). Hệ thống ký hiệu Hungary được sử dụng rộng rãi ở các độ tuổi sớm hơn trong lập trình (ví dụ FORTRAN, C99) khi thông tin kiểu không sẵn có như một công cụ của các IDE.

Hệ thống Hungary Ký hiệu < Apps Hungary Notation

Nếu bạn đang làm việc trong lớp học cấp cao hơn hoặc phương pháp (ví dụ như điều khiển lớp/phương pháp dùng định nghĩa cho các ứng dụng C# của bạn), notating kiểu dữ liệu đơn giản có thể không đủ để mô tả biến/đối tượng. Do đó, chúng tôi sử dụng Ký hiệu Apps Hungary trong trường hợp này. Ví dụ: nếu mục đích của phương pháp của bạn là truy xuất đường dẫn có thể thực thi và hiển thị thông báo lỗi nếu không tìm thấy, thay vì lưu ý rằng đó là loại string, chúng tôi lưu ý thông tin quan trọng hơn để mô tả biến/đối tượng để người lập trình hiểu rõ hơn về mục đích của biến/obejct:

private string mPathExe; 
private string msgNotFound; 
0

Đó là về hiệu quả. Mất bao nhiêu thời gian để gán giá trị sai cho một biến. Có tuyên bố biến chính xác là về đạt được hiệu quả. Đó là về khả năng đọc. Nó về sau các mẫu hiện có. Nếu bạn muốn sáng tạo, hãy thiết kế giao diện người dùng, làm kiến ​​trúc hệ thống. Nếu lập trình của bạn, nó nên được thiết kế để giúp bạn làm việc nhóm thành viên dễ dàng hơn: không phải của bạn. Mức tăng 2% về hiệu quả là một tuần bổ sung mỗi năm. Đó là 40 giờ đã đạt được. Tăng năng suất con người được thực hiện bằng cách kết hợp hiệu quả.

0

Ký pháp Hungary đã tìm thấy mục đích sử dụng chính đầu tiên với ngôn ngữ lập trình BCPL. BCPL là viết tắt của Trước ngôn ngữ lập trình C và là một ngôn ngữ cổ (được thiết kế năm 1966), mọi thứ đều là một từ từ. Trong tình huống đó, ký hiệu Hungary có thể giúp kiểm tra kiểu mắt thường.

Nhiều năm đã trôi qua kể từ đó ...

Đây là những gì mới nhất Linux kernel documentation (tính đến năm 2016) nói (mỏ đậm):

Encoding loại của một hàm thành tên (vì vậy -called Hungarian ký hiệu) là bộ não bị hư hại - trình biên dịch biết các loại anyway và có thể kiểm tra những và nó chỉ gây nhầm lẫn cho lập trình viên.

hãy cũng lưu ý rằng có hai loại ký hiệu Hungarian:

  • Systems Hungary ký hiệu: Các tiền tố mã hóa vật lý loại dữ liệu.

  • Ký hiệu tiếng Hungary ứng dụng: Tiền tố mã hóa hợp lý loại dữ liệu.

Hệ thống Ký pháp Hungary không còn được đề xuất do dự phòng kiểm tra loại do lần tăng do khả năng trình biên dịch. Tuy nhiên, bạn vẫn có thể sử dụng ký hiệu Apps Hungarian nếu trình biên dịch không kiểm tra các loại dữ liệu lôgic cho bạn. Theo quy tắc chung, ký hiệu Hungari là tốt nếu và chỉ khi nó mô tả ngữ nghĩa không có sẵn theo cách khác.

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