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) [đã đóng]


37

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 đó dù sao thì một khái niệm giống boolhoặc floatkhô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?



7
Bạn đang sử dụng ngôn ngữ lập trình nào?
Larry Coleman

3
Trên thực tế nó không ổn - bạn nên có một tiêu chuẩn mã hóa (chính thức hoặc mặt khác), theo tôi nó không bao giờ tốt ... nhưng những người khác có thể không đồng ý.
Murph

@Larry: Chúng tôi đang sử dụng chủ yếu là C và C ++, với sự xuất hiện của Trình biên dịch và Lua ở đây và đó.
bastibe

11
@Paperflyer, các tiêu chuẩn / quy tắc mã hóa không dành cho khách hàng, chúng dành cho nhóm phát triển. Trừ khi bạn tin rằng các nhà phát triển tương tự sẽ ở trong đội ngũ nhân viên mãi mãi (không thực tế), tôi tin chắc rằng bạn nên thiết lập và tuân theo các tiêu chuẩn mã hóa. Nó dẫn đến các hệ thống dễ bảo trì hơn, giúp nhân viên mới tăng tốc nhanh hơn và thống nhất hơn. Điều đó đang được nói, tôi đồng ý rằng ký hiệu Hungary đã được chứng minh là dư thừa, và là một di tích của quá khứ. Những cái tên được suy nghĩ kỹ càng quan trọng hơn, đặc biệt là với các IDE mạnh hơn nhiều đang được sử dụng ngày nay.
Mark Freedman

Câu trả lời:


77

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 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 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 của tiếng Hungary gốc "thực": Ứ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 nWidth, nhưng pxWidthhoặc emWidth(tương ứng với "chiều rộng tính bằng pixel" hoặc "chiều rộng tính theo chiều rộng"). Không strNamenhưng sNamehay usName(đối với "tên an toàn" hay "tên không an toàn" tương ứng - hữu ích khi chấp nhận đầu vào từ người dùng: dây 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ó có lỗi như pxArea = emWidth * emHeighthiển nhiên).

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


2
Hãy xem bài viết của Simonyi về chủ đề này: Anh ấy là người ban hành tiếng Hungary gốc, và phiên bản của anh ấy là phiên bản hữu ích. msdn.microsoft.com/en-us/l Library / aa260976 (v = vs.60) .aspx
Michael Kohne

1
Cần có một số cách để bao gồm các đơn vị trong một loại tùy chỉnh nếu bạn thực sự cần nó (tương tự cho các chuỗi an toàn / không an toàn). Tuy nhiên, tôi có thể thấy rằng bạn có thể gặp phải các vấn đề về hiệu năng khi làm điều đó (chẳng hạn, bạn sẽ không muốn bọc một float trong một lớp chẳng hạn). Trong F #, nó giới thiệu đơn vị tính năng đo, về cơ bản là thêm thông tin loại bổ sung để nhân đôi, chỉ cho mục đích này.
Scott Whitlock

1
Trong mã xử lý đầu vào của người dùng, tôi thấy nó hữu ích với tiền tố dữ liệu người dùng với rawnghĩa làrawUsername
zzzzBov

1
@ Hủy bỏ một tùy chọn khác sẽ là một typedef gõ mạnh
jk.

1
@JBR: Bạn đã thực sự đọc câu trả lời? Trong "Ứng dụng Hungary", không phảis là cho hay cái gì đó, mà là "an toàn" (hoặc tôi cũng đã nghe "chuỗi an toàn"). string

31

đại từ Bạn verbShould adverbNever verbUse adjectiveHungarian nounNotation, preposeitionIt verbMakes collivenounEverything adverbSo so sánhBloody adjectiveHard infinitiveTo verbRead.


6
Khiến tôi mỉm cười ... nghề giáo, nhưng "đến" là một giới từ, không phải là nguyên bản. "để đọc" là một nguyên bản.
DrAl

@dral tất nhiên, đó là trong sổ đăng ký hài hước, không phải là ngữ pháp kỳ dị: D
smirkingman

1
Điều đó thật tuyệt vời, làm tôi cười. :)
Corv1nus

26

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. Vâng, các thuật toán phải là âm thanh, nhưng mã phải được duy trì bởi tất cả mọi người không chỉ là 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ó những công dụng của nó, với một IDE hiện đại hỗ trợ các hành vi kiểu 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. Tệ hơn nữa, 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.


21

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


8
Nó còn tệ hơn cả "dư thừa". Đối với một số tình huống phức tạp, thật khó để có được đúng. Cụ thể, mỗi lớp bạn xác định trong ứng dụng của mình cần viết tắt. Sau khi xác định 20 lớp hoặc hơn, bạn sẽ không viết tắt một chữ cái. Bây giờ thì sao Một hỗn hợp của một chữ cái và hai chữ cái? Điều gì về các tham chiếu phức tạp đến một yếu tố của cấu trúc dữ liệu? Con trỏ tới mảng ánh xạ của danh sách để ánh xạ từ số nguyên sang chuỗi? Làm thế nào một chữ viết tắt của điều đó sẽ hữu ích?
S.Lott

13

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 các 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, s16ADCValuecó 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 một 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 nhập bởi người dùng 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 làm cho 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 đượ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 sở thích.


Bạn nên làm rõ những ngôn ngữ bạn đang nói về. Vì bạn đang làm việc với phát triển nhúng, tôi giả sử bạn đang sử dụng C? Tiếng Hungary có nghĩa trong C, nhưng không phải bằng các ngôn ngữ hiện đại hơn.
JacquesB

9

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 hệ thống loại. (Lưu ý: nó không phải là một hệ thống kiểu tĩnh . Miễn là nó bắt được cá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 chấp nhận của Ký hiệu Hungary. (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 Hungarian Notation 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 ra 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ì?

Vâ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 đó chính xác là 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 :-)


Tôi sẽ bỏ phiếu này lên 50 lần nếu tôi có thể.
Larry Coleman

1
Lập luận rất thú vị! Tôi chỉ có thể thử điều đó trong dự án hiện tại của tôi. typedef meter float...
bastibe

6

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

Nơi duy nhất mà Hệ thống Hungary được bảo vệ 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, nhưng tất cả các chức năng đều nằm 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 biến và trường đá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.


1
Trên thực tế, các IDE (hoặc plugin) tốt thường có khả năng tái cấu trúc khá mạnh mẽ có thể thay đổi tên biến dễ dàng.
bastibe

4
Hiểu, nhưng tiếng ồn thêm trong kiểm soát phiên bản cho thay đổi tên cũng không giúp được gì. Hãy nói rằng giá trị gia tăng không biện minh cho chi phí bảo trì.
Berin Loritsch

sẽ phụ thuộc vào ngôn ngữ cũng như một số người có sự hỗ trợ trực tiếp cho UoM được gõ cứng hoặc gõ typedefs
jk.

6

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.

Những gì chúng ta nên làm là đặt tên cho các biến của chúng ta tốt :

  • Tránh tên quá chung chung. Đừng đặt tên cho nó zkhi đó 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ó phoneBillhay 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ó trên trái đất MyFuncTempStringCharacterIndex? Đó là một trò đùa buồn. Gọi nó Poshoặc thậm chí inế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ổ rwTabPositionvà 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 về việc 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ứ trộn lẫn.

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 là 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ằng cách 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 càng ngắn càng tốt, có ý nghĩa khi cần thiết và luôn rõ ràng .


Đây là gần như chính xác những gì các tiêu chuẩn của chúng tôi là. Sự khác biệt duy nhất là chúng tôi thích Trường hợp Pascal khi đặt tên mọi thứ sao cho Viết hoa là nhất quán.
DForck42

5

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 mã định danh trong chương trình của mình, bạn không cần sử dụng ký hiệu Hungary. isConnectedluôn luôn dễ đọc và dễ hiểu hơn boolConnected.


2
Tôi hoàn toàn đồng ý! Đây là những gì họ gọi là 'Ứng dụng Hungary' trái ngược với 'Hệ thống Hungary'.
bastibe

@bastibe: Không, đây là cái mà họ gọi là tên mô tả. Ứng dụng Hungary dựa vào chữ viết tắt.
JacquesB

2

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 (fe 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 lastNamelà một System.String, 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

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ế là 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à gạch dưới cho tên biến (tôi thấy cái này cuối cùng 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 ký tự AT MOST 90, 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)
)

1

Đồ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.


2
Tôi thấy điều này (mà IDE giúp) một lập luận kém - khi bạn viết mã, vâng, bạn sẽ có lợi ích đó. Nhưng có bất kỳ số lượng các trường hợp (cam kết, xem xét, khác biệt / đổ lỗi, vv) mà bạn có thể không có hỗ trợ đó có sẵn.
Murph

Bạn sai rồi !!!!! ;) Điểm công bằng, tôi vẫn sẽ không sử dụng tiếng Hungary!
ozz
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.