Lợi ích của việc không sử dụng ký hiệu Hungary là gì?

Một trong những điều tôi đấu tranh là không sử dụng ký hiệu Hungary. Tôi không muốn phải đi đến định nghĩa biến chỉ để xem nó là loại gì. Khi một dự án được mở rộng, thật tuyệt khi có thể nhìn vào một biến có tiền tố là 'bool' và biết rằng nó đang tìm kiếm đúng / sai thay vì giá trị 0/1 .

Tôi cũng làm rất nhiều việc trong SQL Server. Tôi tiền tố các thủ tục được lưu trữ của tôi với 'sp' và các bảng của tôi với 'tbl', không đề cập đến tất cả các biến của tôi trong cơ sở dữ liệu tương ứng.

Tôi thấy ở khắp mọi nơi mà không ai thực sự muốn sử dụng ký hiệu Hungary, đến mức họ tránh nó. Câu hỏi của tôi là, lợi ích của việc không sử dụng ký hiệu Hungary là gì và tại sao phần lớn các nhà phát triển tránh nó như bệnh dịch hạch?

Bởi vì mục đích ban đầu của nó (xem http://www.joelonsoftware.com/articles/Wrong.html và http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) đã bị hiểu lầm và nó đã bị (và ab) được sử dụng để giúp mọi người nhớ loại biến là gì khi ngôn ngữ họ sử dụng không được nhập tĩnh. Trong bất kỳ ngôn ngữ gõ tĩnh nào, bạn không cần thêm tiền tố bổ sung để cho bạn biết loại biến là gì. Trong nhiều ngôn ngữ script chưa được chỉnh sửa, nó có thể giúp ích, nhưng nó thường bị lạm dụng đến mức trở nên hoàn toàn khó sử dụng. Thật không may, thay vì quay trở lại ý định ban đầu của ký hiệu Hungary, mọi người chỉ biến nó thành một trong những điều "xấu xa" mà bạn nên tránh.

Ký hiệu Hungary trong ngắn hạn được dự định để tiền tố biến với một số ngữ nghĩa. Ví dụ: nếu bạn có tọa độ màn hình (trái, trên, phải, dưới), bạn sẽ tiền tố biến với vị trí màn hình tuyệt đối với " abs" và biến có vị trí liên quan đến cửa sổ có " rel". Theo cách đó, nó sẽ rõ ràng đối với bất kỳ người đọc nào khi bạn chuyển một tọa độ tương đối sang một phương thức yêu cầu các vị trí tuyệt đối.

cập nhật (để phản hồi bình luận của delnan)

Nên tránh IMHO phiên bản bị lạm dụng như bệnh dịch hạch vì:

• nó phức tạp hóa việc đặt tên. Khi (ab) sử dụng ký hiệu Hungary, sẽ luôn có các cuộc thảo luận về mức độ cụ thể của các tiền tố. Ví dụ: listboxXYZhoặc MyParticularFlavourListBoxXYZ.
• nó làm cho tên biến dài hơn mà không giúp hiểu được biến đó dùng để làm gì.
• nó đánh bại đối tượng của bài tập khi để tránh các tiền tố dài, chúng được rút ngắn thành chữ viết tắt và bạn cần một từ điển để biết ý nghĩa của mỗi từ viết tắt. Là một uisố nguyên không dấu? một giao diện đếm không được ước tính? một cái gì đó để làm với giao diện người dùng? Và những điều đó có thể nhận được lâu dài . Tôi đã thấy các tiền tố của hơn 15 ký tự dường như ngẫu nhiên được cho là truyền đạt chính xác loại var nhưng thực sự chỉ làm bí ẩn.
• nó hết hạn nhanh Khi bạn thay đổi loại biến, mọi người luôn quên (lol) quên cập nhật tiền tố để phản ánh thay đổi hoặc cố tình không cập nhật nó vì điều đó sẽ kích hoạt thay đổi mã ở mọi nơi mà var được sử dụng ...
• nó phức tạp khi nói về mã bởi vì "@g." cho biết: Tên biến với ký hiệu Hungary thường là khó phát âm bảng chữ cái súp. Điều này ức chế khả năng đọc và thảo luận về mã, bởi vì bạn không thể 'nói' bất kỳ tên nào.
• ... nhiều hơn nữa mà tôi không thể nhớ lại vào lúc này. Có lẽ bởi vì tôi đã có niềm vui khi không phải đối phó với ký hiệu Hungary bị lạm dụng trong một thời gian dài ...

Ký hiệu Hungary là một kiểu chống đặt tên trong môi trường lập trình hiện đại và hình thức Tautology .

Nó vô dụng lặp lại thông tin không có lợi ích và chi phí bảo trì bổ sung. Điều gì xảy ra khi bạn thay đổi intthành một loại khác như longbây giờ, bạn phải tìm kiếm và thay thế toàn bộ cơ sở mã của mình để đổi tên tất cả các biến hoặc chúng hiện sai về mặt ngữ nghĩa, tệ hơn là nếu bạn đã sao chép loại trong tên.

Nó vi phạm nguyên tắc DRY. Nếu bạn phải đặt tiền tố cho các bảng cơ sở dữ liệu của mình bằng một chữ viết tắt để nhắc nhở bạn rằng đó là một bảng, thì bạn chắc chắn không đặt tên cho các bảng của mình đủ mô tả về mặt ngữ nghĩa. Tương tự như vậy đối với mọi thứ khác mà bạn đang làm điều này với. Nó chỉ là gõ thêm và làm việc không có lợi hay có lợi với môi trường phát triển hiện đại.

Wikipedia có một danh sách các ưu điểm và nhược điểm của ký hiệu tiếng Đức và do đó có thể cung cấp câu trả lời toàn diện nhất cho câu hỏi này. Những điều đáng chú ý cũng là một bài đọc khá thú vị.

Lợi ích của việc không sử dụng ký hiệu tiếng Đức về cơ bản chỉ là tránh những nhược điểm của nó:

• Ký hiệu Hungary là không cần thiết khi trình kiểm tra kiểu được thực hiện bởi trình biên dịch. Trình biên dịch cho các ngôn ngữ cung cấp kiểm tra loại đảm bảo việc sử dụng biến tự động phù hợp với loại của nó; kiểm tra bằng mắt là dư thừa và có thể có lỗi của con người.

• Tất cả các môi trường phát triển tích hợp hiện đại hiển thị các loại biến theo yêu cầu và tự động gắn cờ các hoạt động sử dụng các loại không tương thích, làm cho ký hiệu phần lớn trở nên lỗi thời.

• Ký hiệu Hungary trở nên khó hiểu khi được sử dụng để biểu diễn một số thuộc tính, như trong a_crszkvc30LastNameCol: một đối số tham chiếu không đổi, giữ nội dung của một cột cơ sở dữ liệu LastNamethuộc loại varchar(30)khóa chính của bảng.

• Nó có thể dẫn đến sự không nhất quán khi mã được sửa đổi hoặc chuyển. Nếu loại biến được thay đổi, trang trí trên tên của biến sẽ không phù hợp với loại mới hoặc tên của biến phải được thay đổi. Một ví dụ đặc biệt nổi tiếng là WPARAMloại tiêu chuẩn và wParamtham số chính thức đi kèm trong nhiều khai báo chức năng hệ thống Windows. 'W' là viết tắt của 'word', trong đó 'word' là kích thước từ gốc của kiến ​​trúc phần cứng của nền tảng. Ban đầu nó là loại 16 bit trên kiến ​​trúc từ 16 bit, nhưng đã được đổi thành kiến ​​trúc từ 32 bit trên kiến ​​trúc từ 32 bit hoặc loại 64 bit trên kiến ​​trúc từ 64 bit trong các phiên bản sau của hệ điều hành trong khi vẫn giữ lại tên gốc (loại cơ bản thực sự của nó làUINT_PTR, nghĩa là, một số nguyên không dấu đủ lớn để giữ một con trỏ). Trở kháng ngữ nghĩa, và do đó, sự nhầm lẫn và không nhất quán của lập trình viên từ nền tảng đến nền tảng, dựa trên giả định rằng 'w' là viết tắt của 16-bit trong các môi trường khác nhau đó.

• Hầu hết thời gian, biết sử dụng một biến ngụ ý biết loại của nó. Hơn nữa, nếu việc sử dụng một biến không được biết đến, nó không thể được suy ra từ loại của nó.

• Ký hiệu Hungary giảm mạnh các lợi ích của việc sử dụng các trình soạn thảo mã giàu tính năng hỗ trợ hoàn thành tên biến, vì lập trình viên phải nhập toàn bộ trình xác định kiểu trước.

• Nó làm cho mã ít được đọc hơn, bằng cách làm xáo trộn mục đích của biến với các loại tiền tố không cần thiết và phạm vi.

• Thông tin loại bổ sung có thể không đủ thay thế tên mô tả nhiều hơn. Ví dụ sDatabase, không nói cho người đọc biết nó là gì. databaseNamecó thể là một tên mô tả nhiều hơn.

• Khi tên đủ mô tả, thông tin loại bổ sung có thể là dự phòng. Ví dụ firstNamerất có thể là một chuỗi. Vì vậy, đặt tên nó sFirstNamechỉ thêm lộn xộn vào mã.

Bản thân tôi không sử dụng ký hiệu này, vì tôi không thích tiếng ồn kỹ thuật không cần thiết. Tôi hầu như luôn biết mình đang xử lý loại nào và tôi muốn có một ngôn ngữ sạch trong mô hình miền của mình, nhưng tôi viết chủ yếu bằng các ngôn ngữ được gõ tĩnh và mạnh.

Là một vấn đề cụ thể của MS SQL Server:

Bất kỳ thủ tục được lưu trữ nào có tiền tố 'sp_' đều được tìm kiếm đầu tiên trong cơ sở dữ liệu Master chứ không phải là quy trình được tạo. Điều này sẽ gây ra sự chậm trễ trong quy trình được lưu trữ được thực thi.

IMO lợi ích lớn nhất của việc không sử dụng tiếng Hungary là thực tế nó buộc bạn phải sử dụng tên có ý nghĩa . Nếu bạn đặt tên đúng cho các biến, bạn cần biết ngay loại đó là gì hoặc có thể suy ra nó khá nhanh trong bất kỳ hệ thống nào được thiết kế tốt. Nếu bạn cần dựa vào strhoặc blntệ hơn tất cả các objtiền tố để biết loại biến là gì, tôi sẽ cho rằng nó chỉ ra vấn đề đặt tên - nói chung là tên biến kém hoặc quá chung chung để truyền đạt ý nghĩa.

Trớ trêu thay, từ kinh nghiệm cá nhân, kịch bản chính mà tôi đã thấy tiếng Hungary được sử dụng là lập trình "vận chuyển hàng hóa" (tức là các mã khác sử dụng nó, vì vậy hãy tiếp tục sử dụng nó chỉ vì) hoặc trong VB.NET để giải quyết vấn đề thực tế là ngôn ngữ không phân biệt chữ hoa chữ thường (ví dụ Person oPerson = new Personvì bạn không thể sử dụng Person person = new Personvà Person p = new Personquá mơ hồ); Thay vào đó, tôi cũng đã thấy tiền tố "the" hoặc "của tôi" (như trong Person thePerson = new Personhoặc xấu hơn Person myPerson = new Person), trong trường hợp cụ thể đó.

Tôi sẽ thêm lần duy nhất tôi sử dụng tiếng Hungary có xu hướng dành cho điều khiển ASP.NET và đó thực sự là vấn đề được lựa chọn. Tôi thấy nó rất xấu khi gõ TextBoxCustomerNamehoặc CustomerNameTextBoxso với đơn giản hơn txtCustomerName, nhưng thậm chí điều đó cảm thấy "bẩn". Tôi cảm thấy một số loại quy ước đặt tên nên được sử dụng cho các điều khiển vì có thể có nhiều điều khiển hiển thị cùng một dữ liệu.

Tôi sẽ chỉ tập trung vào SQL Server kể từ khi bạn đề cập đến nó. Tôi thấy không có lý do gì để đặt 'tbl' trước một cái bàn. Bạn chỉ có thể nhìn vào bất kỳ mã tQuery nào và phân biệt một bảng bằng cách sử dụng nó. Bạn sẽ không bao giờ Select from stored_procedure.hoặc Select from table(with_param)muốn làm UDF hoặc Execute tblTableOrViewNamethích một thủ tục được lưu trữ.

Các bảng có thể bị nhầm lẫn với Chế độ xem, nhưng khi nói đến cách chúng được sử dụng; không có sự khác biệt, vậy điểm là gì? Ký hiệu Hungary có thể giúp bạn tiết kiệm thời gian tìm kiếm nó trong SSMS (dưới bảng hoặc lượt xem?), Nhưng đó là về nó.

Các biến có thể trình bày một vấn đề, nhưng chúng cần phải được khai báo và thực sự, bạn dự định sử dụng một biến như thế nào? Cuộn một vài dòng không nên là vấn đề lớn trừ khi bạn viết các thủ tục rất dài. Nó có thể là một ý tưởng tốt để phá vỡ mã dài một chút.

Những gì bạn mô tả là một nỗi đau, nhưng giải pháp Ký hiệu Hungary không thực sự giải quyết được vấn đề. Bạn có thể xem mã của người khác và thấy rằng loại biến có thể bị thay đổi, hiện cần phải thay đổi tên biến. Chỉ còn một điều nữa để quên đi. Và nếu tôi sử dụng VarChar, bạn sẽ cần nhìn vào câu lệnh khai báo để biết kích thước. Tên mô tả có thể sẽ giúp bạn tiếp tục. @PayPeriodStartDate giải thích khá nhiều về chính nó.

Một điều nữa để thêm vào là, bạn sẽ sử dụng chữ viết tắt nào cho toàn bộ khung như .NET? Vâng, thật đơn giản để nhớ rằng btnđại diện cho một nút và txtđại diện cho một hộp văn bản. Tuy nhiên, bạn có ý nghĩ gì cho một cái gì đó như thế StringBuildernào? strbld? Thế còn CompositeWebControl? Bạn có sử dụng một cái gì đó như thế này:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Một trong những điểm không hiệu quả của ký hiệu Hungary là, bằng cách có các khung lớn hơn và lớn hơn, nó đã chứng minh không chỉ không thêm lợi ích, mà còn tăng thêm độ phức tạp cho các nhà phát triển, vì giờ đây họ phải học các tiền tố không đạt tiêu chuẩn ngày càng nhiều.

Theo cách nhìn của tôi về mọi thứ, Ký hiệu Hungary là một loại bùn để đi xung quanh một hệ thống loại không đủ mạnh. Trong các ngôn ngữ cho phép bạn xác định loại của riêng mình, việc tạo ra một loại mới mã hóa hành vi mà bạn mong đợi là tương đối tầm thường. Trong câu nói của Joel Spolsky về Ký hiệu Hungary, ông đưa ra một ví dụ về việc sử dụng nó để phát hiện các cuộc tấn công XSS có thể bằng cách chỉ ra rằng một biến hoặc chức năng là không an toàn (chúng tôi) hoặc an toàn, nhưng vẫn dựa vào lập trình viên để kiểm tra trực quan. Thay vào đó, nếu bạn có một hệ thống loại có thể mở rộng, bạn có thể chỉ cần tạo hai loại mới là UnsafeString và SafeString, sau đó sử dụng chúng khi thích hợp. Như một phần thưởng, loại mã hóa trở thành:

SafeString encode(UnsafeString)

và không truy cập vào phần bên trong của UnsafeString hoặc sử dụng một số chức năng chuyển đổi khác trở thành cách duy nhất để chuyển từ UnsafeString sang SafeString. Nếu tất cả các hàm đầu ra của bạn thì chỉ lấy các phiên bản của SafeString, nó sẽ không thể xuất ra một chuỗi không thoát [baren shiganigans với các chuyển đổi như StringToSafeString (someUnsafeString.ToString ())].

Rõ ràng là tại sao cho phép hệ thống loại kiểm tra mã của bạn tốt hơn so với cố gắng làm điều đó bằng tay, hoặc có thể là mắt trong trường hợp này.

Trong một ngôn ngữ như C tất nhiên, bạn bị lừa rằng int là int là int và bạn không thể làm gì nhiều về điều đó. Bạn luôn có thể chơi các trò chơi với các cấu trúc nhưng điều gây tranh cãi là liệu đó có phải là một cải tiến hay không.

Đối với cách giải thích khác của Ký hiệu Hungary, IE có tiền tố với loại biến, điều đó thật ngu ngốc và khuyến khích các thực hành lười biếng như đặt tên biến là uivxwFoo thay vì một cái gì đó có ý nghĩa như CountOfP People.

Ký hiệu Hungary gần như hoàn toàn vô dụng trong một ngôn ngữ gõ tĩnh. Đây là một tính năng IDE cơ bản để hiển thị loại biến bằng cách đặt chuột lên trên nó hoặc bằng các phương tiện khác; hơn nữa, bạn có thể thấy loại đó là gì bằng cách tìm một vài dòng ở nơi nó được khai báo, nếu không có loại suy luận. Toàn bộ điểm của suy luận kiểu là không có tiếng ồn của loại lặp đi lặp lại ở mọi nơi, do đó, ký hiệu của Cameron thường được xem là một điều xấu trong các ngôn ngữ có kiểu suy luận.

Trong các ngôn ngữ được gõ động, đôi khi nó có thể giúp ích, nhưng với tôi nó cảm thấy không phổ biến. Bạn đã từ bỏ các chức năng của mình bị giới hạn trong các tên miền / tên miền chính xác; nếu tất cả các biến của bạn được đặt tên theo ký hiệu của Lynn, thì bạn chỉ đang sao chép những gì một hệ thống loại sẽ cung cấp cho bạn. Làm thế nào để bạn biểu thị một biến đa hình có thể là một số nguyên hoặc một chuỗi trong ký hiệu của Cameron? "IntStringX"? "IntOrStringX"? Nơi duy nhất tôi từng sử dụng ký hiệu của Lynn là trong mã lắp ráp, bởi vì tôi đã cố gắng lấy lại những gì tôi nhận được nếu tôi có một hệ thống loại, và đó là điều đầu tiên tôi từng mã hóa.

Dù sao, tôi có thể quan tâm ít hơn những gì mọi người đặt tên cho biến của họ, mã có thể vẫn sẽ không thể hiểu được. Các nhà phát triển lãng phí quá nhiều thời gian cho những thứ như kiểu và tên biến, và vào cuối ngày, bạn vẫn nhận được vô số thư viện với các quy ước hoàn toàn khác nhau trong ngôn ngữ của bạn. Tôi đang phát triển một ngôn ngữ tượng trưng (ví dụ: không dựa trên văn bản) trong đó không có tên biến, chỉ có các định danh duy nhất và tên được đề xuất cho các biến (nhưng hầu hết các biến vẫn không có tên được đề xuất vì đơn giản là không tồn tại tên hợp lý cho họ); khi kiểm tra mã không tin cậy, bạn không thể phụ thuộc vào tên biến.

Như thường lệ trong trường hợp như vậy, tôi sẽ đăng câu trả lời trước khi đọc câu trả lời từ những người tham gia khác. 

Tôi thấy ba "lỗi" trong tầm nhìn của bạn: 

1) Nếu bạn muốn biết loại biến / tham số / thuộc tính / cột, bạn có thể di chuột hoặc nhấp vào nó và nó sẽ được hiển thị, trong hầu hết các IDE hiện đại. Tôi không biết bạn đang sử dụng công cụ nào, nhưng lần trước tôi bị buộc phải làm việc trong môi trường không cung cấp tính năng này là vào thế kỷ 20, ngôn ngữ là COBOL, không phải là Fortran, và ông chủ của tôi không hiểu tại sao tôi lại rời đi. 

2 / Các loại có thể thay đổi trong chu kỳ phát triển. Một số nguyên 32 bit có thể trở thành số nguyên 64 bit tại một số điểm, vì những lý do chính đáng không được phát hiện khi bắt đầu dự án. Vì vậy, đổi tên intX thành longX hoặc để nó với một tên chỉ ra loại sai là nghiệp xấu. 

3) Những gì bạn đang yêu cầu thực tế là sự dư thừa. Dự phòng không phải là mô hình hoặc thói quen thiết kế rất tốt. Ngay cả con người cũng miễn cưỡng với quá nhiều dư thừa. Ngay cả con người cũng miễn cưỡng với quá nhiều dư thừa. 

Tôi tin rằng đang rất cần đến Lynn là một triệu chứng .
Một triệu chứng của quá nhiều biến toàn cục ... hoặc có các hàm quá dài không thể xác định được .

Nếu định nghĩa biến của bạn không có trong tầm nhìn, thông thường, bạn đã gặp rắc rối.
Và nếu các chức năng của bạn không tuân theo một số quy ước đáng nhớ , thì một lần nữa, rắc rối lớn.

Đó là ... khá nhiều lý do tại sao nhiều nơi làm việc lao ra, tôi cho rằng.

Nó có nguồn gốc từ ngôn ngữ mà cần nó.
Vào thời điểm các biến toàn cầu bonanza . (vì thiếu các lựa chọn thay thế)
Nó phục vụ chúng tôi tốt.

Việc sử dụng thực duy nhất chúng tôi có cho nó hôm nay là Joel Spolsky một .
Để theo dõi một số thuộc tính cụ thể của biến, như độ an toàn của nó .

( vd: Có phải biến safeFoobarcó ánh sáng màu xanh lá cây được đưa vào truy vấn SQL không?
- Như được gọi safe, vâng, vâng)

Một số câu trả lời khác nói về các chức năng của trình soạn thảo giúp nhìn thấy loại biến khi bạn di chuột lên nó. Theo quan điểm của tôi, những thứ đó cũng là một vấn đề đối với sự tỉnh táo của mã . Tôi tin rằng chúng chỉ có nghĩa là để tái cấu trúc , vì nhiều tính năng khác cũng vậy, (như chức năng gấp) và không nên được sử dụng trên mã mới.

Tôi nghĩ rằng những lý do không sử dụng ký hiệu Hungary đã được bao phủ bởi các áp phích khác. Tôi đồng ý với ý kiến ​​của họ.

Với cơ sở dữ liệu, tôi sử dụng ký hiệu Hungary cho các đối tượng DDL hiếm khi được sử dụng trong mã, nhưng nếu không thì sẽ va chạm trong không gian tên. Chủ yếu điều này được đưa xuống các chỉ mục tiền tố và các ràng buộc được đặt tên với loại của chúng (PK, UK, FK và IN). Sử dụng một phương thức nhất quán để đặt tên cho các đối tượng này và bạn sẽ có thể chạy một số xác nhận bằng cách truy vấn siêu dữ liệu.

lý do nó được tránh là vì các hệ thống mà vi phạm DRY (tiền tố chính xác là loại mà trình biên dịch và IDE (tốt) có thể lấy được)

các ứng dụng có tiền tố OTOH với việc sử dụng biến (ví dụ: ScrxMouse là tọa độ rìu trên màn hình, đây có thể là một kiểu int, ngắn, dài hoặc thậm chí là một loại tùy chỉnh (typedefs thậm chí sẽ cho phép bạn thay đổi dễ dàng))

sự hiểu lầm của các hệ thống là những gì đã phá hủy thành phố tốt nhất

Giả sử chúng ta có một phương thức như thế này (trong C #):

int GetCustomerCount()
{
    // some code
}

Bây giờ trong mã chúng tôi gọi nó như thế này:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

Các int không cho chúng ta biết nhiều. Thực tế là một cái gì đó là một int không cho chúng ta biết những gì trong đó. Bây giờ, giả sử, thay vào đó, chúng tôi gọi nó như thế này:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Bây giờ chúng ta có thể thấy mục đích của biến là gì. Nó có quan trọng nếu chúng ta biết đó là một int?

Tuy nhiên, mục đích ban đầu của tiếng Hungary là để bạn làm điều gì đó như thế này:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Điều này là tốt miễn là bạn biết những gì c là viết tắt của. Nhưng bạn phải có một bảng tiền tố tiêu chuẩn và mọi người sẽ phải biết chúng, và bất kỳ người mới nào cũng sẽ phải học chúng để hiểu mã của bạn. Trong khi đó customerCounthoặc countOfCustomerslà khá rõ ràng thoạt nhìn.

Tiếng Hungary có một số mục đích trong VB trước khi Option Strict Ontồn tại, bởi vì trong VB6 và trước đó (và trong VB .NET với Option Strict Off) VB sẽ ép buộc các loại, vì vậy bạn có thể làm điều này:

Dim someText As String = "5"
customerCount = customerCount + someText

Điều này là xấu, nhưng trình biên dịch sẽ không nói với bạn như vậy. Vì vậy, nếu bạn đã sử dụng tiếng Hungary, ít nhất bạn sẽ có một số chỉ báo về những gì đang xảy ra:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

Trong .NET, với kiểu gõ tĩnh, điều này là không cần thiết. Và tiếng Hungary quá thường được sử dụng để thay thế cho việc đặt tên tốt. Hãy quên tiếng Hungary và chọn tên tốt thay thế.

Tôi đã tìm thấy rất nhiều lý lẽ tốt để chống lại, nhưng một trong những điều tôi không thấy: công thái học.

Trước đây, khi tất cả những gì bạn có là chuỗi, int, bool và float, các ký tự sibf sẽ là đủ. Nhưng với chuỗi + ngắn, các vấn đề bắt đầu. Sử dụng toàn bộ tên cho tiền tố hoặc str_name cho chuỗi? (Trong khi tên hầu như luôn luôn là chuỗi - phải không?) Điều gì với một lớp Street? Tên càng ngày càng dài và ngay cả khi bạn sử dụng CamelCase, thật khó để biết tiền tố loại kết thúc ở đâu và tên biến bắt đầu từ đâu.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

Được rồi - bạn có thể sử dụng gạch chân, nếu bạn chưa sử dụng chúng cho mục đích khác hoặc sử dụng CamelCase nếu bạn sử dụng gạch chân quá lâu:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

Điều đó thật quái dị và nếu bạn làm điều đó, bạn sẽ có

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

Hoặc bạn sẽ kết thúc bằng việc sử dụng các tiền tố vô dụng cho các trường hợp tầm thường, như các biến vòng lặp hoặc count. Khi nào gần đây bạn sử dụng một ngắn hoặc dài cho một quầy? Nếu bạn tạo ra ngoại lệ, bạn sẽ thường mất thời gian, suy nghĩ về việc có cần tiền tố hay không.

Nếu bạn có nhiều biến, chúng thường được nhóm trong một trình duyệt đối tượng là một phần của IDE của bạn. Bây giờ nếu 40% bắt đầu với i_ cho int và 40% với s_ cho chuỗi và chúng được sắp xếp theo thứ tự bảng chữ cái, thật khó để tìm thấy phần quan trọng của tên.

Một nơi mà tôi vẫn thường xuyên sử dụng hậu tố Hungary hoặc hậu tố tương tự là trong bối cảnh có cùng một dữ liệu ngữ nghĩa ở hai dạng khác nhau, như chuyển đổi dữ liệu. Điều này có thể trong trường hợp có nhiều đơn vị đo lường hoặc có nhiều dạng (ví dụ: Chuỗi "123" và số nguyên 123).

Tôi tìm thấy những lý do được đưa ra ở đây vì không sử dụng nó hấp dẫn vì không áp đặt tiếng Hungary cho người khác, mà chỉ gợi ý nhẹ nhàng, để quyết định thực hành của riêng bạn.

Mã nguồn của chương trình là giao diện người dùng theo đúng nghĩa của nó - hiển thị thuật toán và siêu dữ liệu cho người bảo trì - và sự dư thừa trong giao diện người dùng là một ưu điểm, không phải là một tội lỗi . Xem, ví dụ, các hình ảnh trong " Thiết kế của mọi thứ " và nhìn vào các cánh cửa có nhãn "Đẩy" trông giống như bạn kéo chúng, và tại các vòi bia, các nhà khai thác đã hack vào các điều khiển lò phản ứng hạt nhân quan trọng bởi vì bằng cách nào đó "lơ lửng chúng trong IDE "không đủ tốt.

"Chỉ di chuột trong IDE" không phải là lý do để không sử dụng tiếng Hungary - chỉ một lý do mà một số người có thể không thấy hữu ích. Số dặm của bạn có thể khác nhau.

Ý tưởng rằng Hungary áp đặt một gánh nặng bảo trì đáng kể khi các loại biến thay đổi là ngớ ngẩn - bạn có thường xuyên thay đổi các loại biến không? Ngoài ra, việc đổi tên biến rất dễ dàng:

Chỉ cần sử dụng IDE để đổi tên tất cả các lần xuất hiện. -Gander, trả lời Ngỗng

Nếu tiếng Hungary thực sự giúp bạn nhanh chóng tìm kiếm một đoạn mã và duy trì nó một cách đáng tin cậy, hãy sử dụng nó. Nếu không, đừng. Nếu người khác nói với bạn rằng bạn sai về trải nghiệm của chính mình, tôi khuyên họ có thể là người có lỗi.