Đấu tranh không sử dụng ký hiệu Hungary

10

Tôi đã thấy tranh luận và chống lại Hệ thống Hungary . Trong một số năm, tôi đã làm việc với một dự án cũ sử dụng hệ thống này bằng cách đặt tên cho mọi biến, hàm với tiền tố của loại biến, ví dụ: strName, intAge, btnSubmit, v.v.) (Tôi biết các tiền tố Ứng dụng Hungary gốc theo loại biến, không phải loại). Tôi muốn dự án tiếp theo của mình từ bỏ nó hoàn toàn, nhưng tôi thấy khó khăn hơn khi đặt tên cho những thứ tương tự mà không cần dùng đến nó.

Hãy nói rằng tôi có một biểu mẫu web để thu thập địa chỉ email và lưu trữ chúng trong bảng cơ sở dữ liệu và nút gọi hàm lưu địa chỉ vào db.

Nếu tôi đang sử dụng ký hiệu kiểu Hungary, tôi có thể gọi hộp txtEmaillà nút btnEmailvà giá trị có trong hộp văn bản strEmail. Sau đó tôi có thể sử dụng một chức năng storeEmail(strEmail)để lưu trữ email. Tôi có một quy ước rõ ràng ở đây, rõ ràng mỗi biến là gì.

Điều gì sẽ là thực tiễn tốt nhất để đặt tên cho các biến này

không cần dùng đến Hệ thống Hungary,
mà không làm cho chúng dài hoặc khó hiểu
và với một quy ước rõ ràng để sử dụng trên toàn bộ dự án của tôi?

naming hungarian

— sợ hãi
nguồn

2

Có lẽ có điều gì đó không đúng với phần còn lại của quy ước đặt tên hoặc kích thước chức năng của bạn, nếu bạn gặp khó khăn khi tìm tên duy nhất.

Bạn đang sử dụng công nghệ gì? Các tiền tố này dường như tự cho vay đối với Biểu mẫu web.

— StuperUser

Tôi đang sử dụng ASP.NET (có C # phía sau)

— sợ hãi vào

@delnan - Bạn có thể giải thích rõ hơn không? Tại sao kích thước chức năng làm cho việc đặt tên dễ dàng hơn?

— sợ hãi

@fearofours: Một hàm nhỏ hơn cần ít biến hơn và ít biến hơn rõ ràng có nghĩa là xung đột ít biến hơn. Điều đó giả định tất nhiên bạn đặt mọi biến trong phạm vi nhỏ nhất có thể.

8

Điểm cuối cùng của bạn là quan trọng nhất - bất cứ điều gì bạn cần phải nhất quán trong dự án của bạn và với các đồng nghiệp của bạn. Có hai cách chính để đạt được sự nhất quán và nếu có thể bạn nên sử dụng cả hai. Đầu tiên sử dụng một công cụ để kiểm tra các quy ước đặt tên tại thời điểm xây dựng. Trong thế giới .Net, StyleCop sẽ là một ví dụ điển hình cho một công cụ như vậy. Cách thứ hai để có được sự thống nhất là có các đánh giá ngang hàng về tất cả các mã, để tất cả các bạn có thể theo dõi.

Hai điểm khác của bạn dường như đang hỏi về một sự thay thế. Tôi không chắc bạn cần một giải pháp thay thế; quan điểm về tiếng Hungary không còn phổ biến là nó được sử dụng để giải trừ loại khi hệ thống và công cụ loại một chút, chúng ta sẽ nói, ít nghiêm ngặt hơn. Tức là nếu bạn đang lập trình bằng C và chuyển con trỏ xung quanh cách duy nhất để theo dõi loại đó là sử dụng tiếng Hungary. Bây giờ, nếu bạn đang sử dụng một ngôn ngữ như C # hoặc Java, bạn sẽ không sử dụng các con trỏ (hoặc rất hiếm khi), do đó, nhu cầu đối với bất kỳ loại tiếng Hungary nào sẽ biến mất. Ngoài ra, các IDE hiện đại cho phép bạn nhìn thấy loại rất dễ dàng bằng cách di chuột qua biến hoặc tệ nhất là sử dụng một số phím tắt để xem khai báo gốc. Vì vậy, tôi không nghĩ rằng bạn cần bất kỳ loại ký hiệu nào, chỉ cần đặt tên biến theo những gì nó làm. Nếu đó là một địa chỉ email, chỉ cần sử dụng "email" hoặc "

— Steve
nguồn

2

Sẽ khó khăn hơn một chút khi biểu mẫu / trang / cửa sổ / bất cứ thứ gì có nút cho email, hộp văn bản cho email và có thể là một tiện ích / điều khiển khác cho email ...

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner Không nhất thiết phải như vậy. Hộp văn bản có thể là emailAddressInput trong đó nút là emailAddressSubmit và đại diện bên trong chỉ đơn giản là emailAddress.

— Jonathan

@Jonathan: Điểm tốt.

— Thất vọngWithFormsDesigner

3

Khi xử lý các biểu mẫu web / biểu mẫu Windows / công cụ đồ họa khác, sẽ hợp lý khi sử dụng Hệ thống Hungary vì bạn có thể có các điều khiển được liên kết rất chặt chẽ với nhau, ví dụ như hộp văn bản và nhãn đi kèm; bạn có thể đặt tên cho chúng txtEmailvà lblEmailđể phân biệt chúng. Theo kinh nghiệm của tôi, điều này là phổ biến và thực sự hữu ích.

Nhưng trong mã phía sau của bạn, loại đặt tên này là không cần thiết. Nếu bạn có một biến loại stringđang được sử dụng để lưu trữ email, chỉ cần đặt tên cho nó email. Nếu, vì một số lý do, bạn bị lẫn lộn, hầu hết các IDE sẽ cho phép bạn di chuột qua nó và xem loại của nó. (Lý tưởng nhất là trong công cụ OO, nó có thể là một thuộc tính của một số đối tượng và user.Emailthậm chí còn rõ ràng hơn.)

Tôi nghĩ rằng nếu bạn có nhiều hơn một đối tượng được khai báo trong mã của bạn không phải là điều khiển GUI có thể được đặt tên chính xác email, thì điều gì đó vốn đã sai với thiết kế của bạn.

— Andrew Arnold
nguồn

1

Thực tế txt và lbl không phải là tiếng Hungary, txt chỉ là viết tắt của Text và lbl viết tắt cho Nhãn, không có lý do gì để không sử dụng từ có độ dài đầy đủ, ví dụ EmailText và EmailLabel trên một biểu mẫu. Hungary sẽ là loại, trong cả hai trường hợp này là một chuỗi.

— Steve

1

@Steve Haigh - Không, tôi đang nói về chính các điều khiển. Bạn có một đối tượng thuộc loại "hộp văn bản" được gọi là txtEmail và một đối tượng thuộc loại "nhãn" được gọi là lblEmail. Không phải trong số họ là chuỗi. Chúng có thể có các thuộc tính chuỗi, nhưng bản thân chúng không phải là chuỗi.

— Andrew Arnold

1

Ồ xin lỗi. Phải, tất nhiên. Mặc dù vậy, không có lý do gì để không sử dụng một tên mô tả nhiều hơn như EmailTextBox. Chỉ vì VS tạo ra một tên nghèo không có nghĩa là bạn phải giữ nó. Tuy nhiên, trong bối cảnh của các hình thức, các chữ viết tắt txt và lbl được hiểu rõ đến mức tôi có thể không lo lắng trong trường hợp đó.

— Steve

3

Điều gì làm cho một biến "quá dài"?

Thay vì txtEmail, btnEmailbạn có thể sử dụng UserEmailText, UserEmailButtonvà AdminEmailText,AdminEmailButton

Vấn đề với điều này là bạn có thể bắt đầu cảm thấy rằng biến bắt đầu dài ra:

AdminEmailIsValid bắt đầu giới hạn về thời gian tôi cho phép biến.

Ngoài ra, bạn có thể bắt đầu nhận thấy rằng bạn đang sử dụng lại một tập hợp các biến và một tập hợp các thao tác trên các biến đó. Đây là những gì OOP được thiết kế cho. Thay vì một tập hợp các biến, hãy tạo một đối tượng chung:

class EmailForm
  var textBox, button, text
  function storeEmail()

Sau đó, bạn có thể khởi tạo một biến mới dưới dạng một lớp và sử dụng cùng một ký hiệu dấu chấm để truy cập dữ liệu của bạn:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Tất nhiên, điều này được nhắm mục tiêu vào các ngôn ngữ sử dụng mô hình OOP, nhưng phần lớn các ngôn ngữ phát triển web phổ biến là hướng đối tượng hoặc cho phép mã hướng đối tượng (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, v.v. ).

— zzzzov
nguồn

Tôi không thấy lợi thế của UserEmailText đối với txtEmail - bạn chỉ nhập vào loại chứ không phải tiền tố. Tôi thích "Đây là những gì OOP được thiết kế cho", mặc dù.

— sợ hãi

@fearoffours, OP thừa nhận có vấn đề với tên duy nhất, tôi đã thêm ví dụ đó như một cách mô tả để phân biệt giữa hai biến tương tự ( UserEmailTextvà AdminEmailTextcụ thể). Tôi thường sử dụng các kiểu hậu tố vì nó cho vay để chuyển sang một lớp UserEmailText-> UserEmail.text-> User.email.texttùy thuộc vào mức độ trừu tượng / chức năng là cần thiết.

— zzzzBov

OK xem bạn đến từ đâu. +1 để so sánh hậu tố / lớp. Ồ, và tôi là OP!

— sợ hãi

@fearoffours, lol rất tiếc ...

— zzzzBov