it-swarm-vi.com

Bạn có tiền tố tên biến với một chữ viết tắt của các loại biến? (Ký hiệu Hungary)

Trong công việc hiện tại của tôi, không có hướng dẫn mã hóa. Mọi người khá nhiều mã theo cách anh ấy muốn. Điều đó là tốt, vì công ty là nhỏ.

Tuy nhiên, một anh chàng mới gần đây đã đề xuất luôn sử dụng Ký hiệu Hungary. Cho đến bây giờ, một số người trong chúng ta đã sử dụng một số loại Ký hiệu Hungary, một số người trong chúng ta thì không. Bạn biết đấy, đó là một công ty kỹ thuật, vì vậy phong cách mã hóa không thực sự quan trọng miễn là các thuật toán là âm thanh.

Cá nhân, tôi cảm thấy rằng các chữ viết tắt loại nhỏ là loại dư thừa. Một cái tên được suy nghĩ kỹ lưỡng thường mang lại thông điệp tương tự. (Hơn nữa, hầu hết mã của chúng tôi phải chạy trên một số DSP kỳ lạ, trong đó một khái niệm như bool hoặc float dù sao cũng không tồn tại).

Vì vậy, bạn cảm thấy thế nào về ký hiệu Hungary? Bạn có dùng nó không? Tại sao?

37
bastibe

Khi hầu hết mọi người nói "Ký hiệu Hungary", họ thực sự đang nói về " Hệ thống tiếng Hungary ".

Hệ thống Hungary hoàn toàn vô dụng và nên tránh. Không cần mã hóa loại của biến trong tên của nó. Tuy nhiên, Hệ thống Hungary thực sự là một sự hiểu lầm về gốc , "thực" tiếng Hungary: Ứng dụng tiếng Hungary.

Trong Ứng dụng Hungary, bạn không mã hóa "loại" trong tên biến, bạn mã hóa "loại" của biến. Vì vậy, không phải nWidth, mà là pxWidth hoặc emWidth (tương ứng với "width in pixel" hoặc "width in ems"). Không phải strName mà là sName hoặc usName (tương ứng với "tên an toàn" hoặc "tên không an toàn" - hữu ích khi chấp nhận đầu vào từ người dùng: chuỗi không an toàn).

Cá nhân, tôi thường không bận tâm với một trong hai. Trừ khi tôi đang làm một cái gì đó rõ ràng là chuyển đổi "loại" của một giá trị (ví dụ: tôi đã sử dụng tiền tố "px" và "em" trong quá khứ vì nó mắc lỗi như pxArea = emWidth * emHeight rõ ràng).

Xem thêm, bài viết của Joel, " Tạo mã sai nhìn sai ."

77
Dean Harding

đại từ Bạn verbShould adverbNever verbUse tính từ.

31
smirkingman

Thứ nhất:

Bạn biết đấy, đó là một công ty kỹ thuật, vì vậy phong cách mã hóa không thực sự quan trọng miễn là các thuật toán là âm thanh.

Phong cách mã hóa làm vấn đề bất kể công ty. Đúng, các thuật toán have là âm thanh, nhưng mã phải có thể được duy trì bởi mọi người, không chỉ nhà phát triển ban đầu. Có một tiêu chuẩn mã hóa bao gồm các yếu tố phong cách sẽ giúp bạn đạt được điều đó. Tôi không nói rằng tất cả các mã phải giống hệt nhau về kiểu dáng - điều đó sẽ phản tác dụng, nhưng cần có một mức độ nhất quán.

Bây giờ vào ký hiệu Hungary:

Mặc dù nó có công dụng của nó, với IDE hiện đại hỗ trợ các hành vi loại IntelliSense, không cần thiết phải bao gồm loại biến trong tên của nó. Thông tin này có sẵn cho bạn theo những cách khác. nó có thể làm cho mã khó đọc hơn nếu bạn phải thay đổi loại biến trong tương lai.

26
ChrisF

Đừng sử dụng nó. Nó là dư thừa và làm cho mã khó đọc hơn.

21
codeape

Rất nhiều cuộc tranh luận về (Hệ thống) Ký hiệu Hungary phụ thuộc vào khu vực làm việc. Tôi đã từng rất kiên quyết đứng về phía "không thể nào!", Nhưng đã làm việc vài năm tại một công ty nơi nó được sử dụng để phát triển nhúng, tôi có thể thấy một số lợi thế của nó trong một số ứng dụng nhất định và nó chắc chắn đã phát triển trong tôi .

Hệ thống Hungary

Từ những gì tôi có thể nói, Hệ thống Hungary có xu hướng được sử dụng rất nhiều trong lĩnh vực nhúng. Trong các ứng dụng PC, trình biên dịch sẽ giải quyết rất nhiều vấn đề liên quan đến sự khác biệt giữa (ví dụ) chuỗi, số nguyên và giá trị dấu phẩy động. Trên nền tảng được nhúng sâu, bạn thường quan tâm hơn về sự khác biệt giữa các số nguyên không dấu 8 bit, số nguyên có chữ ký 16 bit, v.v ... Trình biên dịch (hoặc thậm chí không tuân theo quy tắc MISRA được thi hành) không phải lúc nào cũng nhận ra. Trong trường hợp này có tên biến như u8ReadIndex, s16ADCValue có thể hữu ích.

Ứng dụng Hungary

Ứng dụng Hungary có những lợi thế nhất định khi nói đến các ứng dụng PC/Web, ví dụ như cung cấp sự khác biệt trực quan giữa các chuỗi 'không an toàn' và chuỗi 'an toàn' (nghĩa là các chuỗi được người dùng nhập vào và những người đã thoát hoặc đọc từ tài nguyên nội bộ hoặc bất cứ điều gì ). Trình biên dịch không có kiến ​​thức về sự khác biệt này.

Vấn đề ở đây là gì?

Sử dụng (Hệ thống hoặc Ứng dụng) Tiếng Hungary là tất cả về việc tạo mã sai nhìn sai.

Nếu bạn đang sao chép một chuỗi không an toàn thẳng vào một chuỗi an toàn mà không thoát ra được, nó sẽ sai nếu bạn sử dụng Ứng dụng Hungary.

Nếu bạn nhân một số nguyên đã ký với một số nguyên không dấu, trình biên dịch sẽ (thường âm thầm) quảng bá số đã ký thành (một số rất lớn) không dấu, có thể dẫn đến lỗi: Các hệ thống Hungary làm cho điều này sai.

Trong cả hai tình huống này, ký hiệu Hungary (Ứng dụng/Hệ thống) có xu hướng làm cho các đánh giá mã chính thức nhanh hơn vì ít tham khảo lại loại biến.

Nhìn chung

Nhìn chung, ý kiến ​​của tôi là điều quan trọng nhất là bạn có một tiêu chuẩn mã hóa. Cho dù sử dụng Hệ thống Hungary, Ứng dụng Hungary hay không phải là vấn đề ưu tiên cá nhân hoặc nhóm, giống như lựa chọn loại thụt lề, v.v. Tuy nhiên, có những lợi thế nhất định cho toàn bộ nhóm phát triển làm việc theo cùng một sở thích.

13
DrAl

Mục đích của Ký hiệu Hungary là mã hóa thông tin vào mã định danh mà không thể mã hóa theo cách khác trong hệ thống loại. Ý kiến ​​riêng của tôi là nếu thông tin này đủ quan trọng để được mã hóa, thì nó đủ quan trọng để được mã hóa trong hệ thống loại, nơi nó có thể được kiểm tra chính xác. Và nếu thông tin không quan trọng, vậy thì tại sao bạn lại muốn làm lộn xộn mã nguồn của mình với nó?

Hoặc, để nói rõ hơn: thông tin loại thuộc về hệ thống loại. (Lưu ý: không nhất thiết phải là hệ thống loại tĩnh . Miễn là nó bắt được lỗi loại, tôi không quan tâm khi nó bắt được chúng.)

Một vài câu trả lời khác đề cập đến Đơn vị đo lường là cách sử dụng Ký hiệu Hungary được chấp nhận. (Tôi hơi ngạc nhiên khi chưa có ai nhắc đến Tàu quỹ đạo Khí hậu Sao Hỏa của NASA, vì điều đó dường như xuất hiện mọi lúc trong các cuộc thảo luận về Ký hiệu Hungary).

Đây là một ví dụ đơn giản trong F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Nhìn kìa, Ma, không có người Hung!

Nếu tôi đã sử dụng Ký hiệu Hungary thay vì các loại ở đây, điều đó sẽ không giúp tôi một chút:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Trình biên dịch cho phép nó đi thẳng qua. Bây giờ tôi đang dựa vào một con người để phát hiện lỗi cơ bản là gì. Đó không phải là những gì một trình kiểm tra loại dành cho?

Thậm chí tốt hơn, sử dụng ngôn ngữ lập trình Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Vì vậy, tóm lại: Tôi không thích Ký hiệu Hungary. Bạn không bao giờ nên sử dụng nó.

Điều đó đang được nói, tôi nghĩ rằng sử dụng ký hiệu Hungary là một ý tưởng tốt. Đợi đã, cái gì?

Đúng! Trong trường hợp cụ thể này , bạn đã đề cập:

Hơn nữa, hầu hết các mã của chúng tôi phải chạy trên một số DSP kỳ lạ, trong đó một khái niệm như bool hoặc float không tồn tại

Nhưng đó là chính xác trường hợp sử dụng hợp lý duy nhất cho Ký hiệu Hungary!


PS: Tôi hết lòng khuyên bạn nên nhìn vào Frink. Hướng dẫn sử dụng của nó chứa một số trò đùa rắm tuyệt vời nhất từng có. Đó cũng là một ngôn ngữ khá tuyệt :-)

9
Jörg W Mittag

QUÁI GÌ KHÔNG!

Đừng sử dụng ký hiệu Hungary hoặc bất kỳ ký hiệu nào khác. Là lập trình viên, chúng ta không nên sử dụng "ký hiệu" cho tên biến của mình.

Điều chúng ta nên làm là đặt tên cho các biến của chúng ta thật tốt:

  • Tránh tên quá chung chung. Đừng đặt tên nó là z khi đó là một biến lớp đại diện cho một đối tượng được đặt tên, giả sử, hóa đơn điện thoại. Gọi nó là phoneBill hoặc PhoneBill.
  • Tránh tên quá cụ thể. Khi một cái gì đó rõ ràng mà không có thông tin bổ sung không bao gồm nó. Nếu nó chỉ là một biến chỉ mục chuỗi để lặp qua các ký tự của chuỗi và bạn chỉ sử dụng nó một lần trong hàm MyFunc, tại sao bạn lại gọi nó là MyFuncTempStringCharacterIndex? Đó là một trò đùa buồn. Gọi nó là Pos hoặc thậm chí i nếu bạn thích. Trong bối cảnh, lập trình viên tiếp theo sẽ dễ dàng hiểu ý nghĩa của nó.

  • Khi không tham gia vào tên chung hoặc cụ thể như thế nào, hãy xem xét tên miền và bối cảnh của các ý nghĩa có thể khác. Trong trường hợp hẹp, có hai mục dễ bị nhầm lẫn, giống nhau được sử dụng theo cùng một cách, thì việc đưa ra tiền tố hoặc hậu tố để biểu thị sự khác biệt đó là điều tốt. Giữ nó càng ngắn càng tốt.

Như những người trả lời khác đã nói, chính trường hợp hẹp này đã bắt đầu "Ứng dụng Hungary", để phân biệt giữa các phép đo liên quan đến cửa sổ rwTabPosition và liên quan đến tài liệu rdTabPosition. Nhưng trong một ứng dụng thực hiện mọi thứ liên quan đến tài liệu, đừng thêm bất kỳ hành trình nào! Trên thực tế, tại sao không sử dụng ý tưởng của Jorg W Mittag tạo ra một loại thực tế mới từ nó? Sau đó, bạn không thể có được những thứ hỗn hợp.

Trong hầu hết mọi lĩnh vực, việc thêm các công cụ có mật độ ý nghĩa tối thiểu sẽ làm giảm ý nghĩa tổng thể và dễ hiểu. Đây một ví dụ từ Ben Franklin . Và một ví dụ khác: có thể bằng tiếng Anh để trang trí các từ của chúng ta bằng một phần của bài phát biểu. Đó là nhiều thông tin hơn, phải không? Trong trường hợp người mới bắt đầu học tiếng Anh bị nhầm lẫn, nó có thể thực sự hữu ích với họ, phải không? Đọc điều này và cho tôi biết bạn nghĩ nó hữu ích như thế nào đối với sự hiểu biết lâu dài và việc truyền đạt thông tin hiệu quả:

vrbDo advnot vrbuse nouHungarian danh từ cnjor adjany điều chỉnh danh từ. PrepAs nouprogrammer, prowe vrbshould advnot verbe nouuses "nounotation" prpfor proour điều chỉnh nounames.

Bởi thêm thông tin, tôi đã làm cho nó hoàn toàn đau đớn để đọc.

Vì vậy, quên ký hiệu. Quên các tiền tố đặc biệt mà bạn luôn thêm. Theo tôi, hướng dẫn thực sự duy nhất ở đây nên là:

Giữ tên biến là ngắn càng tốt, vì có ý nghĩa khi cần và luôn luôn không rõ ràng .

6
ErikE

Nó không có ý nghĩa trong một ngôn ngữ hướng đối tượng - mọi thứ đều là một loại rõ ràng khi cố gắng sử dụng nó.

6
billy.bob

Nơi duy nhất Hệ thống Hungary được bảo đảm là có ngôn ngữ được gõ yếu như C. Nó rất quan trọng với C vì không có đối tượng rõ ràng (nó có cấu trúc rõ ràng , nhưng tất cả các chức năng là bên ngoài cấu trúc). Trong một cái gì đó được gõ mạnh hơn như C++, Java và C #, nó không giúp ích gì, và trên thực tế làm cho mọi thứ tồi tệ hơn. Thay đổi mã, và việc thay đổi một loại dễ dàng hơn nhiều so với thay đổi tất cả các địa điểm bạn đang sử dụng tên biến. Đó cũng là công việc bận rộn không cần thiết có xu hướng bị bỏ qua.

Nếu bạn có các đơn vị đo lường, có thể giúp mã hóa tên đó - nhưng cuối cùng cũng có thể gây thêm tiếng ồn. Ví dụ: chúng tôi sẽ khai báo đơn vị đo lường tiêu chuẩn cho những thứ khác nhau mà chúng tôi đang làm việc trong mã của chúng tôi. Ví dụ: chúng ta đang sử dụng độ dốc hoặc độ, mét hoặc feet, khung hoặc mili giây? Khi tiêu chuẩn được đặt cho mã, bất cứ khi nào chúng tôi đọc trong một đơn vị đo, chúng tôi luôn chuyển đổi ngay lập tức thành đơn vị đo lường tiêu chuẩn cho mã.

Lời khuyên của tôi: bắt đầu với các điểm đau hiện tại của bạn và chọn một tiêu chuẩn hợp lý cho phần đó của mã. Quá mức một tiêu chuẩn mã hóa là phản tác dụng. Có rất nhiều giá trị trong việc có các tên trường và biến để đánh vần những gì chúng đại diện và hầu hết thời gian bạn có thể suy luận một cách an toàn loại từ khái niệm này.

6
Berin Loritsch

Mục đích của một định danh quan trọng hơn loại của nó. Nếu bạn sử dụng tên mô tả cho số nhận dạng trong chương trình của mình, bạn không cần sử dụng ký hiệu Hungary. isConnected luôn dễ đọc và dễ hiểu hơn boolConnected.

5
Mudassir

Chúng tôi đã sử dụng tiếng Hungary khi tôi còn là một lập trình viên C++ và điều đó thật tuyệt. Bạn có thể thấy loại biến (ví dụ: BSTR, CString, LPCTSTR hoặc char *) mà không cần tìm kiếm khai báo. Trong những ngày đó, bạn sẽ tìm kiếm khai báo bằng cách thực hiện:

  1. ctrl-nhà
  2. ctrl-F
  3. tên biến
  4. đi vào

Vì vậy, nó quan trọng một chút. Nhưng đâu đó khoảng năm 2000, một vài điều đã xảy ra:

  • các trình soạn thảo đã trở nên đủ thông minh để hiển thị loại biến dưới dạng một chú giải công cụ
  • các biên tập viên đã có một phím tắt "đi đến khai báo" và một cách nhanh chóng để duyệt lại
  • C++ được sử dụng ít hơn và hầu hết các ngôn ngữ khác có ít loại biến hơn. Ví dụ: trong C #, bạn khá chắc chắn lastName là một System.String, bởi vì chỉ có một lớp chuỗi.

Tôi là một trong những người cuối cùng chuyển khỏi Hungary và bây giờ khi tôi đọc mã nguồn cũ, nó thực sự làm tôi khó chịu.

2
Andomar

Tôi chỉ ghét ký hiệu tiếng Anh, tôi thích sử dụng dấu gạch dưới để phân định tên biến.

Trên hết, khi bạn đặt loại là chữ cái đầu tiên ở đầu tên biến của bạn như thế này: float fvelocity; vect vectir; chuỗi ** ppszWord;

tự động hoàn thành sắp xếp tất cả chúng, và bạn gặp khó khăn trong việc tìm kiếm những gì bạn muốn, và mọi người có xu hướng sử dụng những gì họ nghĩ là tốt hơn, và nó không còn là một ký hiệu nữa.

Tôi chỉ thích viết ThingsLikeThat khi tôi cần rất mô tả về biến, bởi vì nó tiết kiệm không gian và thực tế có các mũ làm cho nó dễ đọc hơn.

Những gì tôi thường làm, là đặt tên cho các phương thức và các lớp của tôi với chữ cái đầu tiên là Uppercase và chữ thường cho tên biến và dấu gạch dưới cho tên biến (tôi thấy cái cuối cùng này hữu ích).

Nghiêm túc, tôi thích mọi người quan tâm đến các quy tắc đó: Sử dụng dấu phẩy, số học và dấu ngoặc nhọn với các khoảng trắng có liên quan:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Không quá 80 char trên mỗi dòng hoặc AT MOST 90 ký tự, sử dụng đối số nhiều dòng cho các hàm hoặc dài if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)
2
jokoon

Đồng ý với hầu hết, đó là một phong cách cũ.

Với IDE hiện đại, di chuột nhanh qua một biến cho bạn thấy loại.

1
ozz