Là hệ thống ký hiệu Hungary vẫn là một thực hành hữu ích? [đóng cửa]

Tôi đã tìm kiếm trên diễn đàn, nhưng tôi không thể tìm thấy câu trả lời tại sao nên tránh, chỉ tại sao nó không phải là viên đạn bạc. Vì vậy, tôi không nghĩ rằng câu hỏi này là một bản sao.

Có lý do GIÁ TRỊ tại sao tôi nên học hỏi Hệ thống Hungary mà tôi đã sử dụng không?

Cho đến nay tôi thấy những lợi ích sau khi sử dụng nó:

• Đặt tên biến nhất quán
• Bạn thấy loại mà không cần tìm kiếm (intellisense đã chết / lập chỉ mục một nửa thời gian, vì vậy đây vẫn là một lý do hợp lệ)
• Ngữ nghĩa vẫn có thể được đóng gói vào phần thứ hai của tên

Và những nhược điểm sau:

• Nó làm phiền một số người (không biết tại sao)
• Nếu loại được thay đổi, loại có thể không khớp với cách đặt tên của biến (Tôi không nghĩ đó là lý do hợp lệ, các loại hiếm khi được thay đổi và bạn đã "đổi tên tất cả")

Vậy tại sao:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

tệ hơn:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

Tôi đã từng sử dụng nó (nhiều năm trước) và tôi không còn nữa. Lý do chính là nó không cần thiết trong các ngôn ngữ OO với kiểu gõ mạnh (C ++, Java) mà tôi tình cờ đã sử dụng hầu hết sự nghiệp của mình. Trong các ngôn ngữ này, nếu tôi xác định rõ các loại của mình, trình biên dịch có thể và sẽ thực thi an toàn loại cho tôi. Vì vậy, bất kỳ tiền tố đặt tên chỉ là lộn xộn làm cho tên dài hơn, do đó khó đọc và tìm kiếm hơn.

Trong bất kỳ chương trình OO nào được viết tốt, hầu hết các biến của bạn là (tham chiếu đến) các loại do người dùng xác định. Nếu bạn đặt tiền tố này với cùng một thẻ chung (như ođối với "đối tượng"), bạn sẽ không nhận được bất kỳ lợi ích nào từ nó, chỉ có những hạn chế. Tuy nhiên, nếu bạn đặt tiền tố cho chúng bằng các thẻ cụ thể theo loại, bạn sẽ bị mê hoặc khi cố gắng tìm các chữ viết tắt khác nhau cho hàng ngàn loại khác nhau với tên thường giống nhau * và nhớ thay đổi tất cả khi một loại hoặc tên của nó thay đổi (đó là không hiếm chút nào trong một chương trình được duy trì tốt).

Tất nhiên, điều này không áp dụng cho các ngôn ngữ không phải OO và có thể không áp dụng cho các ngôn ngữ được gõ yếu và / hoặc động (tôi không có kinh nghiệm với các ngôn ngữ này, ngoài C). Không phải là trình soạn thảo / IDE tối ưu mà không có IntelliSense có thể sử dụng (hoặc tương đương cục bộ của nó). Và đây chỉ là 2 xu của tôi. Vì vậy, nếu ký hiệu Hungary làm việc cho nhóm của bạn và dự án của bạn, hãy đi cho nó. Điều quan trọng là phải đồng ý về điều này (cũng như về phong cách mã hóa nhất quán nói chung) trước khi dự án bắt đầu và giữ cho nó nhất quán mọi lúc.

* _{Chỉ là một danh sách ngắn từ dự án hiện tại của chúng tôi: chúng tôi có Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairvà ChargeType, trong số những người khác. Ngoài ra, chúng tôi cũng có Contracts, Countries, Checkouts, Checkins ... và đây chỉ là chữ C, trong một dự án mà thậm chí có thể sẽ không được OP gọi là "có kích thước hợp lý".}

Tuyên bố miễn trừ trách nhiệm: Tôi thực sự là người Hungary, vì vậy tôi tin rằng tôi có thể nói về vấn đề này với chính quyền ;-)

Tại sao là std::vector<string> vecCityNames;xấu?

Vấn đề với ký hiệu Hungary vì nó thường được sử dụng, nếu hồ sơ cho thấy tên thành phố nên được giữ trong một std::deque, tất cả các tên biến đề cập đến một đối tượng loại đó sẽ đột nhiên có một tên sai.

Sau đó bạn sẽ đổi tên tất cả các biến của bạn? Bạn đã bao giờ thử làm điều đó trong một dự án lớn chưa? Với sự giúp đỡ của Murphy (và anh chàng cực kỳ hữu ích ở đó), một người nào đó chắc chắn sẽ sử dụng các biến được gọi là gì đó deqCityNames, làm cho các thay đổi của bạn phá vỡ bản dựng, khiến bạn ngồi hàng giờ với mã mà trong nửa thập kỷ, không ai dám nhìn cả. tại, vì sợ bị một con thú độc cắn.

Tuy nhiên, từ những gì tôi biết, cách Charles Simonyi nghĩ ra tiếng Hungary, tiền tố đã biểu thị các biến số sử dụng ngữ nghĩa , thay vì kiểu cú pháp . Đó là, tiền tố thích hợp cho danh sách tên thành phố của bạn, bất kể nó được triển khai theo loại nào, có thể sẽ là listCityNames(hoặc lstCityNames, nếu listkhông đủ mật mã cho bạn).

Nhưng tôi cho rằng tiền tố đó khá thừa thãi, bởi vì số nhiều ("tên") đã chuyển tải rằng đó là một loạt các thành phố. Điểm mấu chốt: Khi bạn chọn định danh của mình một cách cẩn thận, ký hiệu Hungary hiếm khi cần thiết. OTOH, về mặt thường được sử dụng, về lâu dài, thực sự gây thiệt hại cho mã.

Vì lý do nào, các câu trả lời hiện có ở đây dường như đang nhảy múa xung quanh lý do cho ký hiệu Hungary, mà không nêu rõ. Ký hiệu Hungary rất hữu ích cho việc thêm thông tin loại ( theo nghĩa lý thuyết loại ) khi khó có thể làm như vậy trong chính ngôn ngữ . Khi điều đó xảy ra, thường không khó sử dụng hệ thống kiểu C ++ hoặc Java theo cách mà ký hiệu Hungary (như thường được mô tả) là hoàn toàn thừa, và đây có lẽ là điều dẫn đến phản ứng dữ dội chống lại nó - nó bổ sung thêm công việc cho lập trình viên để duy trì các chú thích đó trong tất cả các biến số của chúng tôi, nhưng cung cấp ít hoặc không có giá trị bổ sung (và thậm chí có thể gây hại, vì mã trông lộn xộn hơn).

Mặt khác, nếu người ta hạn chế sử dụng ký hiệu Hungary để gõ thông tin (một lần nữa, theo nghĩa lý thuyết loại ) thì khôngtự nhiên được gói gọn bởi ngôn ngữ, sau đó nó có thể rất hữu ích. Ví dụ, C và C ++ vượt qua các tham chiếu mảng dưới dạng các kiểu con trỏ, nhưng các tham chiếu và các con trỏ mảng có các hoạt động khác nhau nên được thực hiện đối với chúng: các mảng có thể được lập chỉ mục ngoài phần tử đầu tiên, trong khi các con trỏ thì không. Đây là thông tin hữu ích bị mất cho hệ thống loại ngay khi một mảng được truyền cho hàm dưới dạng đối số. Như vậy, trong nhóm của chúng tôi, chúng tôi đã áp dụng các chú thích tên biến trong mã C và C ++ để phân biệt xem một biến con trỏ có thực sự là một con trỏ tới một phần tử hay một con trỏ tới một mảng. Việc thông qua quy ước này đã chịu trách nhiệm một phần cho việc giảm đáng kể sự xuất hiện của các vấn đề tham nhũng bộ nhớ trong cơ sở mã của chúng tôi.

Nó làm phiền một số người (không biết tại sao)

Lý do nó làm tôi khó chịu là vì nó có một chút tốc độ trên mỗi mã định danh làm chậm quá trình quét mã của tôi. Đó là mAs b If pYou kHad zTo qRead iEnglish cText lLike u This.

Ghét quá mạnh từ, IMO. Bạn có thể viết mã của bạn theo bất kỳ cách nào bạn muốn; Tôi chỉ đơn giản là không thích sử dụng ký hiệu Hungary trong mã của riêng mình và đưa ra một lựa chọn Tôi cũng không muốn phải đọc nó hoặc làm việc với mã đó trong mã của người khác.

Bạn hỏi tại sao một số người thấy ký hiệu Hungary gây phiền nhiễu. Tôi không thể nói thay cho người khác, nhưng những lý do khiến tôi khó chịu là:

1. No thật la xâu xi. Hungary có tên hoàn toàn hợp lý và trả trước số tiền cho một mã. Khi bạn đã nội địa hóa mã này, tôi chắc chắn có ý nghĩa hoàn hảo, nhưng với người không quen biết, nó trông giống như ai đó đã giải phóng trình quản lý tên C ++ trên mã nguồn của tôi.

2. Nó dư thừa. Một khai báo của biến thiết lập kiểu của nó; Tôi không cảm thấy cần phải lặp lại thông tin đó trong tên biến. Điều này không đúng trong mọi ngôn ngữ: ví dụ, trong Perl, các sigils như @ hoặc $ được đặt trước tên biến về cơ bản xác định loại biến, vì vậy bạn không có lựa chọn nào khác ngoài sử dụng chúng.

3. Nó giải quyết một vấn đề mà tôi không có. Các phương thức và hàm không nên quá dài đến nỗi bạn phải khó tìm ra khai báo của một biến hoặc tham số cục bộ và chúng không nên liên quan đến quá nhiều biến khiến bạn gặp khó khăn trong việc theo dõi những gì. Khai báo các biến cục bộ gần với mã sử dụng chúng cũng giúp về mặt này. Trình biên dịch C của quá khứ yêu cầu tất cả các biến cục bộ được khai báo ở đầu hàm, nhưng giới hạn đó đã được loại bỏ từ lâu.

4. Nó không đầy đủ. Ký hiệu Hungary được phát minh cho một ngôn ngữ (BCPL) không có hệ thống loại và sau đó được sử dụng rộng rãi trong ngôn ngữ (C) có số lượng bản địa khá hạn chế. IMO, nó không hoạt động tốt với các ngôn ngữ như C ++ hoặc Java có hệ thống kiểu mở rộng. Tại sao tôi muốn sử dụng tiền tố để chỉ ra loại biến đó là loại gốc, như char [], nhưng không phải là một loại? Thay phiên, nếu tôi bắt đầu phát minh các tiền tố như veccho các lớp, tôi sẽ kết thúc với một hệ thống phân cấp tiền tố lớn song song với hệ thống phân cấp lớp của tôi. Nếu điều đó hấp dẫn bạn, bạn sẽ được chào đón; chỉ nghĩ về nó là làm tôi đau đầu.

5. Nó mơ hồ , ít nhất là như tôi hiểu. Sự khác biệt giữa szFoovà là pszFoogì? Đầu tiên là một chuỗi kết thúc bằng không và thứ hai là một con trỏ đến một chuỗi kết thúc bằng không. Nhưng trong C hoặc C ++, theo như tôi biết, bất kỳ biến chuỗi nào cũng thực sự là một con trỏ, vậy chúng có giống nhau hay không? Tôi nên sử dụng cái nào? Câu trả lời thực sự không quan trọng - vấn đề là tôi không thể nhận ra câu trả lời bằng cách sử dụng ký hiệu được cho là để giúp tôi tránh những loại câu hỏi này. Mặt khác, khai báo của biến phải rõ ràng vì đó là những gì trình biên dịch sử dụng.

Đó là những điều làm tôi khó chịu về ký hiệu Hungary. Mặc dù là một nhóm, tôi không nghĩ họ giải thích đầy đủ lý do tại sao tiếng Hungary bị bỏ rơi phần lớn. Dưới đây là ba lý do lớn nhất mà hầu hết các lập trình viên không sử dụng tiếng Hungary:

1. Không có lý do thuyết phục để sử dụng nó. Xem mục 3 và 4 ở trên. Tôi có lẽ có thể sống với những phiền toái nếu tiếng Hungary mang lại lợi thế lớn cho việc không sử dụng tiếng Hungary, nhưng tôi không thấy điều đó, và dường như hầu hết những người khác cũng không. Có lẽ điều tốt nhất về tiếng Hungary là nó là một quy ước được sử dụng rộng rãi và nếu bạn sử dụng tiêu chuẩn, bạn có thể mong đợi một cách hợp lý các lập trình viên khác có kỹ năng tương tự có thể hiểu được ký hiệu.

2. Ảnh hưởng ngày càng tăng của các công ty không phải là Microsoft. Có lẽ công bằng khi nói rằng hầu hết các lập trình viên đã thông qua ký hiệu Hungary đã làm như vậy bởi vì đó là cách Microsoft viết mã, và nó thường dễ đi theo dòng chảy hơn. Các công ty như Google và Apple có tầm ảnh hưởng lớn hơn nhiều so với trước đây và nhiều lập trình viên hơn bao giờ hết đang áp dụng phong cách của những công ty đó và những công ty khác mà chủ yếu là người Hungary. (Thật công bằng khi chỉ ra rằng bạn vẫn thấy một số tàn dư, ví dụ: cả Google và Apple thường sử dụng tiền tố 'k' cho tên không đổi.)

3. Chính Microsoft đã từ bỏ Hungary. Nếu bạn kiểm tra phần Quy ước đặt tên chung của Microsoft trong hướng dẫn mã hóa của nó, bạn sẽ thấy rằng nó được in đậm: Không sử dụng ký hiệu Hungary.

Theo đó, một lý do hợp lệ để ngừng sử dụng ký hiệu Hungary là:

Sự phổ biến của ký hiệu Hungary đã giảm đến mức quy ước không còn hữu ích. Ngày nay, rất ít lập trình viên sử dụng hoặc thậm chí hiểu tiếng Hungary, và do đó, quy ước ít hiệu quả hơn trong việc truyền đạt thông tin mà nó được cho là. Nếu bạn thấy đó là một cách hữu ích để viết mã trong các dự án cá nhân của riêng bạn, thì có rất ít lý do để dừng lại. Tuy nhiên, nếu bạn viết mã như một phần của nhóm không sử dụng tiếng Hungary, nó có thể trở thành bức tường ngăn cách giữa bạn và phần còn lại của nhóm thay vì chiến lược giao tiếp thành công.

Cho đến nay tôi thấy những lợi ích sau khi sử dụng nó:

• Đặt tên biến nhất quán

Nếu tôi đặt tên cho tất cả các biến của mình theo các ký tự từ The Simpsons, điều đó cũng phù hợp, nhưng nó có phải là một lợi ích không?

• Bạn thấy loại mà không cần tìm kiếm (intellisense đã chết / lập chỉ mục một nửa thời gian, vì vậy đây vẫn là một lý do hợp lệ)

Đây là lý do duy nhất hợp lệ, dựa trên điểm yếu của một công cụ cụ thể ...

• Ngữ nghĩa vẫn có thể được đóng gói vào phần thứ hai của tên

Đó không phải là một lợi ích; bạn chỉ đơn thuần tuyên bố sự vắng mặt của một nhược điểm ( lớn ).

IDE sẽ nói cho tôi biết loại biến là gì khi tôi di chuột qua nó. Vậy tại sao phải sao chép thông tin đó? Về cơ bản, Hệ thống ký hiệu Hungary là vi phạm DRY, với tất cả những cạm bẫy liên quan đến nó. Khi thông tin đó có thể truy cập tầm thường trong một môi trường hiện đại, không có lý do gì để trả giá đó.

Tính nhất quán không phải là một lợi thế của chính nó. Không đặt tên chúng với các loại cũng phù hợp. Bạn sẽ chỉ có sự không nhất quán nếu chỉ một số biến có kiểu của chúng trong tên. Và đóng gói ngữ nghĩa vào phần thứ hai chỉ đơn giản là "Chà, nó không tệ đến thế đâu.", Mọi người khác đều được sử dụng toàn bộ tên cho ngữ nghĩa. Bạn không có bất kỳ lợi thế thực sự được liệt kê.

Một điểm khác với các hình thức ký hiệu truyền thống của Hungary là chúng thường là tiền tố. Có 2 vấn đề imho ở đây:

1) Một người đọc nói chung thường muốn thông tin quan trọng nhất trước tiên, trong hầu hết các dạng tiếng Hungary, thông tin được mã hóa được cho là ít quan trọng hơn so với tên của chính nó.

2) Tiền tố có hiệu lực sắp xếp từ vựng, vì vậy, ví dụ, nếu bạn định sử dụng tiền tố để biểu thị các giao diện hoặc lớp và IDE của bạn cung cấp một danh sách được sắp xếp của các lớp này, các lớp / giao diện liên quan sẽ được tách ra trong danh sách này.

Rõ ràng, điều này xuất phát từ ý kiến, vì vậy sẽ rất khó để làm việc với các sự kiện ở đây. Cá nhân, tôi thấy rằng các đối số cho ký hiệu Hungary chạy hơi mỏng trong các ngôn ngữ hướng đối tượng được gõ mạnh. Theo kinh nghiệm của tôi, các ứng dụng OO có xu hướng xử lý sự phức tạp bằng cách giữ cho các lớp chặt chẽ và súc tích, và điều tương tự có thể được nói về các chức năng. Điều này có nghĩa là tất cả những thứ khác đều bằng nhau, bạn kết thúc bằng:

• Nhiều lớp / loại
• Phương pháp ngắn hơn

Bây giờ, nếu bạn muốn sử dụng ký hiệu Hungary, bạn phải quyết định áp dụng nó trên bảng hay chỉ sử dụng nó cho các loại và lớp đặc quyền nhất định (chẳng hạn như các lớp thư viện lõi). Cái sau không có ý nghĩa gì với tôi, và cái trước dẫn đến "mê cung cố gắng tìm các chữ viết tắt khác nhau cho hàng ngàn loại khác nhau" mà Péter Török đang đề cập. Điều này có nghĩa là có một chi phí đáng kể trong việc duy trì danh sách viết tắt và thường là "đặt tên biến nhất quán" đi ra ngoài cửa sổ.

Điểm thứ hai về các phương thức ngắn hơn có nghĩa là trong hầu hết các trường hợp, bạn sẽ không phải trải qua hàng trăm dòng mã để kiểm tra loại biến là gì. Đặt tên biến cẩn thận hơn một chút sẽ loại bỏ một số câu hỏi khác của bạn - ví dụ như cityNameso với chỉ city. Tôi hy vọng đó cityNamekhông phải là một cái phao :)

Về lý do tại sao nó gây khó chịu cho mọi người - một lần nữa, điều này có lẽ đã được sử dụng cho nó hay không. Nhưng là một người không quen với nó, tôi có thể nói với bạn rằng việc sử dụng ký hiệu Hungary phá vỡ dòng mã cho mắt tôi, khiến cho việc đọc nhanh trở nên khó khăn hơn. Tóm lại, tôi không nói rằng nó không có giá trị (mặc dù tôi đã không thảo luận về một số nhược điểm của nó, về mặt tái cấu trúc, v.v.), tôi đang nói rằng nỗ lực này không đáng giá, đối với các ngôn ngữ OO được gõ mạnh.

Tôi không biết trong ngữ cảnh của C ++ nhưng trong thế giới Java / C #, tôi thích có nhiều tên có ý nghĩa truyền đạt ngôn ngữ hoặc ngữ cảnh miền hơn là nói với tôi đó strFirstNamelà Chuỗi; Rõ ràng đó là một chuỗi, hoặc tên cần phải được cấu trúc lại để truyền đạt ý định tốt hơn. Nếu bạn yêu cầu một tiền tố để biết loại bạn đang làm việc với cái gì, tôi sẽ cho rằng việc đặt tên của bạn không nhất quán, không đủ mô tả hoặc hoàn toàn sai. Trong các ngôn ngữ hiện đại, tôi luôn thích những cái tên dài hơn không để lại sự mơ hồ hơn những cái tên mơ hồ hoặc mơ hồ.

Lần duy nhất tôi sử dụng tiếng Hungary là cho các điều khiển ASP.NET và vì thế IA) không phải gõ một cái gì đó thực sự dài như CustomerFirstNameTextBoxso với txtCustomerFirstNamevà B) Vì vậy, Intellisense sẽ sắp xếp tất cả các loại điều khiển. Tôi cảm thấy "bẩn" ngay cả khi làm điều đó, mặc dù, tôi vẫn chưa tìm thấy một cách tốt hơn.

Meh - đó thực sự là tất cả về sở thích cá nhân, bất kể người ta cố gắng hợp lý hóa các lựa chọn của họ đến mức nào. Cá nhân tôi tuân thủ quy tắc "Khi ở Rome ..." và sử dụng tiếng Hungary trong mã gọi API Windows rất nhiều. Đối với mã độc lập với nền tảng, tôi có xu hướng theo kiểu Thư viện chuẩn C ++.

Câu trả lời nằm trong câu hỏi này: Xin vui lòng cho tôi biết cách đặt tên cho các biến sau:

char * nullTerminedString;
wchar * nullTerminedWideString;
chuỗi stlString;
chuỗi stlWideString;
Cfring mfcString;
BSTR comString;
_bstr_t atlString;

Thêm vào các chuỗi không đổi này, con trỏ tới các chuỗi này và các con trỏ liên tục đến các chuỗi này.

Tôi rất không thích hình thức ký hiệu Hungary mà bạn mô tả. Nguyên nhân? Nó phục vụ không có điểm 90% thời gian.

Ví dụ, một chút mã (tương đương C ++. Thực sự được viết bằng Delphi) từ một dự án cũ mà tôi buộc phải chịu đựng:

pRecords[0]->FooMember=10;

... pRecord là một biến, nó thuộc loại TRecordList. TRecordList *pRecords[10];

Đó là một lớp bao gồm một orioerty tên là FooMember chỉ vào fFooMember ... hoặc mFooMember tùy thuộc vào việc đó là "trường" hay "thành viên" (gợi ý: chúng giống nhau)

Các vấn đề? fFooMembercó thể là một cái gì đó giống như FooMember_ bởi vì chúng tôi sẽ luôn truy cập nó thông qua tài sản công cộng FooMember. pRecords? Rõ ràng đó là một con trỏ từ thực tế là bạn đã bỏ qua nó ở mọi nơi. Danh sách TRecord? Khi nào bạn có thể nhầm lẫn giữa một loại tên và một đối tượng của loại đó? Trình biên dịch sẽ la mắng bạn và các kiểu được sử dụng ở hầu hết các vị trí mà các đối tượng (ngoại trừ các thuộc tính / phương thức tĩnh)

Bây giờ, có một nơi tôi sử dụng ký hiệu tiếng Đức. Đây là khi xử lý nhiều biến UI có cùng tên với các biến UI hoặc biến thông thường khác.

Chẳng hạn, nếu tôi có một mẫu cho Tên của bạn trên đó.

Tôi có một lớp có tên FirstNameForm. Trong đó, lblFirstName và txtFirstName cho nhãn và hộp văn bản tương ứng. Và một thuộc tính FirstName công khai để nhận và đặt tên trong hộp văn bản.

Điều này cũng có thể được giải quyết bằng cách sử dụng FirstNameLabel và FirstNameTextBox nhưng tôi thấy nó sẽ dài để gõ. Đặc biệt là với một cái gì đó như Giới tínhDropDownList và như vậy.

Vì vậy, về cơ bản, ký hiệu của Cameron là, tốt nhất, gây khó chịu ở cấp độ hệ thống và trường hợp xấu nhất có hại (như các câu trả lời khác đưa ra về các vấn đề với tái cấu trúc và tính nhất quán).