Triết lý / lý luận đằng sau tên phương thức vỏ Pascal của C # là gì?


22

Tôi mới bắt đầu học C #. Đến từ một nền tảng trong Java, C ++ và Objective-C, tôi thấy Pascal của C # bao gồm các tên phương thức của nó khá độc đáo và lúc đầu khó sử dụng. Lý do và triết lý đằng sau này là gì?

Tôi đoán đó là vì thuộc tính C #. Không giống như trong Objective-C, trong đó tên phương thức có thể giống hệt như một biến thể hiện, đây không phải là trường hợp với C #. Tôi đoán một trong những mục tiêu có thuộc tính (như với hầu hết các ngôn ngữ hỗ trợ nó) là làm cho các thuộc tính thực sự không thể phân biệt được với các biến và phương thức. Vì vậy, người ta có thể có "int x" trong C # và thuộc tính tương ứng trở thành X. Để đảm bảo rằng các thuộc tính và phương thức không thể phân biệt được, tất cả các tên phương thức tôi đoán cũng sẽ được bắt đầu bằng một chữ cái viết hoa. (Đây chỉ là giả thuyết của tôi dựa trên những gì tôi biết về C # cho đến nay tôi vẫn đang học). Tôi rất tò mò muốn biết làm thế nào hướng dẫn tò mò này ra đời (cho rằng nó '

(EDIT: Theo Pascal-casing, ý tôi là PascalCase (về cơ bản là camelCase nhưng bắt đầu bằng chữ in hoa). Tên phương thức thường bắt đầu bằng một chữ cái viết thường trong hầu hết các ngôn ngữ)


Nếu bạn thấy rằng tất cả các thành viên của một gia đình nào đó có tất cả các bức tường của họ trong tất cả các ngôi nhà của họ được sơn một phù hiệu kỳ lạ, bạn có tò mò tại sao họ lại làm điều đó kỳ lạ như vậy không?
Nocturne

1
Tại sao bạn nghĩ rằng nó được gọi là trường hợp Pascal ?
R. Martinho Fernandes

1
@Martinho Fernandes đó là tên tiêu chuẩn cho phong cách này, hãy kiểm tra Google
Andrey

1
@Nocturne - Vâng. Tôi sẽ tò mò :)
Joel Etherton

1
"Tên phương thức bắt đầu bằng một chữ cái viết thường trong hầu hết các ngôn ngữ" là sai trong kinh nghiệm của tôi. Các quy ước bắt đầu bằng một chữ cái viết hoa - có hoặc không có dấu phân cách từ gạch dưới - khá phổ biến, mặc dù không nhất thiết phải có trong hướng dẫn ngôn ngữ chính thức. Hầu hết các tiêu chuẩn ngôn ngữ không có bất kỳ hướng dẫn phong cách chính thức nào. Dù sao thì cũng có một vài ngôn ngữ (chủ yếu là cũ hơn) và thường có quy ước viết thường mọi thứ vì không nhấn phím là quy tắc lười nhất có nghĩa là bạn không được đánh vần các trường hợp khác nhau được coi là cùng một sự nhầm lẫn .
Steve314

Câu trả lời:


27

Đó là vấn đề của hương vị. Ai đó đã từng quyết định sử dụng kiểu Pascal cho tên và nó đã trở thành một tiêu chuẩn.

Tôi có một phỏng đoán hoang dã rằng đó là Anders Hejlsberg , kiến ​​trúc sư của Delphi, người kế thừa của Pascal. Kiểu vỏ cũng giống như trong C #.


đây sẽ là câu trả lời của tôi : P
DevSolo

@DevSolo xin lỗi, tôi bắt đầu gõ câu trả lời khi có câu hỏi tại Stackoverflow :)
Andrey

Tôi nghĩ rằng những gốc rễ còn đi sâu hơn vào lịch sử cổ đại - xem câu trả lời của tôi dưới đây :)
davka

20

Nếu bạn đang hỏi về lý do, đây là một câu nói thẳng từ miệng ngựa:

Lịch sử xung quanh bài viết Vỏ Pascal và Vỏ lạc đà của Brad Abrams tại blog MSDN

Trong thiết kế ban đầu của Framework, chúng tôi đã có hàng trăm giờ tranh luận về phong cách đặt tên. Để tạo điều kiện cho những cuộc tranh luận này, chúng tôi đặt ra một số điều khoản. Với Anders Heilsberg (nhà thiết kế ban đầu của Turbo Pascal ), một thành viên chủ chốt của nhóm thiết kế, không có gì lạ khi chúng tôi chọn thuật ngữ Vỏ Pascal cho kiểu vỏ được phổ biến bởi ngôn ngữ lập trình Pascal ...

Quy ước Vỏ Pascal viết hoa ký tự đầu tiên của mỗi từ (bao gồm các từ viết tắt trên hai chữ cái) ...

Và đây là hướng dẫn thiết kế: Nguyên tắc thiết kế dành cho nhà phát triển thư viện lớp

Những hướng dẫn này nhằm giúp các nhà thiết kế thư viện lớp hiểu được sự đánh đổi giữa các giải pháp khác nhau. Có thể có những tình huống trong đó thiết kế thư viện tốt yêu cầu bạn vi phạm các nguyên tắc thiết kế này. Những trường hợp như vậy nên rất hiếm, và điều quan trọng là bạn cung cấp một lời biện minh vững chắc cho quyết định của mình. Phần này cung cấp hướng dẫn đặt tên và sử dụng cho các loại trong .NET Framework cũng như hướng dẫn triển khai các mẫu thiết kế chung ...


2
TurboPascallà đứa con của Philip Kahn(aka Borland) rất thuận tiện để Microsoft quên đi. Chính trị ....
davka

1
Các ý kiến ​​về liên kết đầu tiên là tuyệt vời, lol.
jmq

7

Không biết về triết học, nhưng vỏ Pascal dường như phổ biến trên các nền tảng của Microsoft kể từ ít nhất là ngày Win32 API.


8
và tôi vẫn ghét nó, lol.
jmq

2

Tôi không nghĩ rằng có một triết lý cụ thể đằng sau nó. Cần có hướng dẫn và có nhiều điểm có thể ảnh hưởng đến nó:

  • Họ muốn thoát khỏi bất kỳ ký hiệu tiền tố nào (đọc tiếng Đức ở đây)
  • Họ muốn rằng các thành viên địa phương / tư nhân và các thành viên công cộng được phân biệt bằng cách chỉ đọc tên của họ.
  • Họ không muốn mã C # trông giống như mã Java (sử dụng rất nhiều vỏ lạc đà)

Lưu ý rằng hướng dẫn đặt tên này dành cho .NET framework chứ không phải C # nói riêng. Trong VB.NET, một ngôn ngữ không phân biệt chữ hoa chữ thường, quy ước vẫn giữ nguyên, nhưng bạn không thể sử dụng nó để phân biệt các thành viên riêng và công khai theo từng trường hợp.
R. Martinho Fernandes

@Martinho: đồng ý. nhưng tôi vẫn cảm thấy là một trong những lý do.
giải mã

7
+1: "Họ không muốn mã C # trông giống như mã Java (sử dụng rất nhiều vỏ lạc đà)": Tôi rất nghi ngờ bạn đang ở đây!
Giorgio

Điều đáng mỉa mai là mặc dù một số người ghét ký hiệu Hungary, nhưng Java và C # có thể có cả hai ngôn ngữ tốt hơn trong thực tế nếu họ đã áp dụng Ứng dụng Hungary (hoặc quy ước đặt tên khác) để phân biệt các trường loại tham chiếu "sở hữu" một đối tượng có thể thay đổi do đó, đã xác định được những trường hợp xác định một thể hiện loại đột biến không bao giờ bị đột biến , v.v. Ngay cả khi Runtime không quan tâm đến sự khác biệt đó, không thể viết mã hiệu quả và chính xác mà không biết biến nào là loại nào.
supercat

0

Tôi không biết rằng có một "triết lý" đằng sau vỏ bọc ngoài nó đẹp và nhỏ gọn và có thể dễ dàng xuất hiện dưới dạng nhiều từ mà không cần sử dụng dấu gạch dưới.

Có nhiều biến thể của vỏ trong vài thập kỷ qua. Họ đã chuyển từ rất ngắn gọn (xem C và thư viện C tiêu chuẩn) đến dài dòng với dấu gạch dưới ngăn cách mỗi từ. Trong khi quy ước đặt tên thư viện .NET vẫn còn khá dài dòng, tôi nghĩ rằng nó tấn công một số nền tảng ở giữa chừng như vỏ bọc.


5
đừng quên-lisp-style-đặt tên!
R. Martinho Fernandes

@Martinho Fernandes thực sự trong bối cảnh ngôn ngữ giống như c, nó không hợp lệ.
Andrey

Vâng, Lisp đưa khoảng trắng vào tài khoản. (- var1 var2)
Michael K

@Martinho Fernandes: Tất nhiên, điều đó đòi hỏi phải sử dụng khoảng trắng để tách mã thông báo. Đó cũng là COBOL-STYLE-NAMING, điều này làm cho nó trở nên phổ biến đối với các ngôn ngữ mà tôi ngưỡng mộ nhất và ít ngưỡng mộ nhất.
David Thornley

0

Suy đoán hoang dã (nhưng không vô lý, IMHO) - Thiết kế C # được giám sát bởi Niklaus Wirth , nhà phát minh ban đầu của Pascal. Xem kết nối? ... :)

Tò mò # 1: Tôi tích cực nhớ thông báo của .NET và C # (vâng, tôi là người tiền sử ...) và cách Microsoft khoe khoang bằng cách đặt tên của Wirth trên C #. Tuy nhiên, các trang Wikipedia trên (C # và Wirth) không đề cập đến điều này.

Tò mò # 2: Mặc dù nó được gọi PascalCase, nhưng nó đã được phổ biến bởi TurboPascaltrình biên dịch (cuối cùng đã trở thành Borland), chứ không phải ngôn ngữ.


4
và TurboPascal được thiết kế và xây dựng thuận tiện bởi Anders Hejlsberg ...
SWeko

3
Anders Hejlsberg là IIRC, nhà thiết kế chính của Delphi, và đã làm việc rất nhiều cho Turbo Pascal, nhưng ban đầu Turbo Pascal không phải là con của anh ấy (đó là Philip Kahns). Niklaus Wirth đã phát minh ra Pascal ban đầu và đưa nó qua tiêu chuẩn hóa, sau đó thấy tiêu chuẩn bị bỏ qua phần lớn. Ngoài ra, Wirth đã nghỉ hưu gần như toàn bộ cuộc đời của C #, và trước đó sau đó đã thiết kế một số ngôn ngữ kế thừa cho Pascal (gần đây nhất là Oberon 2) nên tôi nghi ngờ anh ta có liên quan trực tiếp đến tất cả. Microsoft khoe khoang lớn tiếng về việc có Hejlsberg trên tàu. Turbo Pascal là một sản phẩm Borland ngay từ đầu.
Steve314

Tôi không ngại hạ cấp - Tôi có đủ điểm trên StackOverflow, nhưng tôi tò mò về lý do
davka
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.