ใครสามารถอธิบายแบบแผนการเข้ารหัสของ C # ให้ฉันได้บ้าง


14

ฉันเพิ่งเริ่มทำงานกับ Unity3D และสคริปต์เป็นหลักด้วย C # ตามปกติแล้วฉันจะเขียนโปรแกรมใน Java ความแตกต่างก็ไม่ดีนัก แต่ฉันยังคงเรียกใช้หลักสูตรความผิดพลาดเพื่อให้แน่ใจว่าฉันกำลังอยู่ในเส้นทางที่ถูกต้อง

อย่างไรก็ตามความอยากรู้ที่ยิ่งใหญ่ที่สุดของฉันกับ C # คือมันใช้อักษรตัวแรกของชื่อเมธอด (เช่น Java: getPrime()C #: GetPrime()aka: Pascal Case) มีเหตุผลที่ดีสำหรับสิ่งนี้หรือไม่? ฉันเข้าใจจากหน้าหลักสูตรความผิดพลาดที่ฉันอ่านซึ่งเห็นได้ชัดว่ามันเป็นแบบแผนสำหรับ. Net และฉันไม่มีทางที่จะเปลี่ยนแปลงมัน แต่ฉันอยากรู้ว่าทำไมมันถึงทำแบบนี้เมื่อเทียบกับกรณีอูฐปกติ (ญาติ?) ที่พูดว่า Java ใช้

หมายเหตุ: ฉันเข้าใจว่าภาษาต่าง ๆ มีระเบียบการเข้ารหัสของตนเอง (วิธีการ Python เป็นตัวพิมพ์เล็กทั้งหมดซึ่งใช้กับคำถามนี้ด้วย) แต่ฉันไม่เคยเข้าใจเลยว่าทำไมมันถึงไม่ทำเป็นมาตรฐาน


18
ผมไม่คิดว่าคุณสามารถดูcamelCaseและPascalCaseและunderscore_caseและกล่าวว่าหนึ่งในนั้นเป็นเรื่องปกติ (แม้จะค่อนข้างปกติ) และคนอื่น ๆ ไม่ได้ ดังที่ @dasblinkenlight พูดมันเป็นทางเลือกโดยพลการ สิ่งเดียวที่ทำให้คุณคิดว่าการประชุม C # ผิดปกติคือคุณ "ปกติโปรแกรมใน Java" และคุ้นเคยกับตัวเลือกโดยพลการที่สร้างขึ้นสำหรับ Java
Carson63000

ใช้ JavaScript แทน .. สำหรับ Unity3D :)
Lipis

@Lipis ทำไม - นอกเหนือจากรสนิยมส่วนตัว? ;-)
ahodder

@AedonEtLIRA เป็นส่วนตัวโดยสิ้นเชิง .. ไม่เป็นไร :) เพลิดเพลินกับ Unity ไม่ว่าคุณจะใช้ภาษาอะไร ..
Lipis

@Lipis จนถึงตอนนี้มันยอดเยี่ยมมาก เสียงระฆังและเสียงดังมากมายและฉันยังไม่ได้ทิ้งเงินลงไป แต่ฉันชอบสไตล์ที่มีโครงสร้างของ C # (c / c ++) และ java
ahodder

คำตอบ:


27

อนุสัญญาการตั้งชื่อแสดงถึงตัวเลือกโดยพลการของผู้จัดพิมพ์ ไม่มีอะไรในภาษาที่ห้ามมิให้คุณตั้งชื่อวิธีการในภาษาจาวา: ตราบใดที่อักขระตัวแรกเป็นตัวอักษร / ขีดล่างและอักขระอื่น ๆ ทั้งหมดเป็นตัวอักษรตัวเลขหรือขีดล่าง C # จะไม่ไป บ่น. อย่างไรก็ตามไลบรารีคลาสที่มาพร้อมกับ. NET ปฏิบัติตามข้อตกลงที่ Microsoft ได้นำมาใช้ภายใน Microsoft ยังเผยแพร่แนวทางเหล่านี้เพื่อให้ผู้อื่นอาจเลือกที่จะนำมาใช้กับไลบรารีคลาสของตนเอง แม้ว่าคุณจะเลือกที่จะทำตามหรือไม่สนใจแนวทางของ Microsoft แต่การที่ผู้อื่นคุ้นเคยกับโค้ดของคุณอาจทำงานได้เร็วขึ้นหากคุณทำตามแนวทางการตั้งชื่อเดียวกัน


อย่างไรก็ตามมักจะมีเหตุผลบางอย่างที่อยู่เบื้องหลังการประชุมและเมื่อฉันอ่าน "มีเหตุผลที่ดีสำหรับสิ่งนี้หรือไม่?" ฉันเข้าใจว่าเป็นคำถามเกี่ยวกับสิ่งที่ไม่ใช่สิ่งที่
greenoldman

Pascal สำหรับสมาชิกสาธารณะ / ภายใน / คงที่และวิธีการทั้งหมด อูฐส่วนตัว ช่วยแยกขอบเขตโทเค็นในขณะที่คุณสแกน thisคำหลักที่ไม่เหมือนกัน ตัวเลือกรูปแบบมีประโยชน์แม้ว่าพวกเขาจะปรากฏตัวเป็นคนต่างด้าว
ก็ตาม

23

อาจเป็นเพราะอิทธิพลของ Pascal / Delphi ผู้สร้าง C # และ Delphi เป็นบุคคลเดียวกันหลังจากทั้งหมด (Anders Hejlsberg)

อนุสัญญาการเข้ารหัส Delphi โดยและขนาดใหญ่ที่เกิดขึ้นจะเป็นเช่นเดียวกับ C # ในด้านนี้; ดูhttp://www.econos.de/delphi/cs.html#ObjectPascal_Proceduresหรือhttp://wiki.delphi-jedi.org/index.php?title=Style_Guide#Method_Naming - ความบังเอิญ?


4
+1 สำหรับสิ่งนี้เพราะมันให้เหตุผลว่าทำไมตัวเลือกที่เจาะจงนี้จึงถูกสร้างขึ้นสำหรับ C #
Maximus Minimus

4

นอกเหนือจากคำตอบอื่น ๆ ที่ทำแล้วการมีอูฐกรณีสำหรับวิธีการหมายความว่าพวกเขาสามารถขัดแย้งกับชื่อสำหรับสมาชิกส่วนตัวพารามิเตอร์และตัวแปรวิธีการที่ใช้กรณีอูฐสำหรับการตั้งชื่อของพวกเขา ใน Java (และ C # 1.0) สิ่งนี้ไม่ได้เกิดขึ้นบ่อยนักเนื่องจากการใช้ผู้รับมอบสิทธิ์นั้นไม่สะดวกและหายาก ใน C # ที่ทันสมัยมันไม่ได้เหมือนกันทุกประการ แต่มันก็ไม่เคยได้ยินมาก่อน


1
ไม่ควรใช้การขีดเส้นใต้ในฟิลด์ส่วนตัวของ C # (ดูblogs.msdn.com/b/brada/archive/2005/01/26/361363.aspxเป็นต้น) แต่มันขัดแย้งและพบบ่อย
เจนส์

1
การใช้เคสเพื่อแยกความแตกต่างระหว่างการสร้างภาษาเป็นความคิดที่ไม่ดีจริง ๆ ไม่ว่าภาษานั้นจะอนุญาตให้คุณทำหรือไม่ก็ตาม
gbjbaanb

4
@Telastyn คำสั่งนั้นค่อนข้างน่าตกใจ ไลบรารีคลาส. NET ส่วนใหญ่ใช้การประชุมนั้น
MattDavey

1
@ Dunk มันเป็นแบบแผนของฉันได้อย่างไร ฉันเป็นเพียงการผ่านความเห็นผมไม่ได้มีความเห็นเกี่ยวกับเรื่องนี้ทางใดทางหนึ่ง :)
MattDavey

2
@MarjanVenema: ไม่แน่ใจว่าสิ่งที่คุณกำลังพูดถึง แต่ C # ค่อนข้างตรงตามตัวพิมพ์ใหญ่และคุณสามารถชนกันระหว่างสมาชิกที่ใส่ซองคล้ายกันได้ สิ่งนี้จะสนุกและน่าตื่นเต้นเมื่อคุณมีภาษาที่ไม่สำคัญเช่น VB.NET ที่คุณกำลังทำงานอยู่ในระดับห้องสมุด
ไวแอตต์บาร์เน็ตต์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.