เหตุใดจึงยังมีการพิจารณาขนาดตัวพิมพ์เล็กและเล็กในภาษาการเขียนโปรแกรม

ฉันไม่เห็นการใช้ความไวของตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ในภาษาการเขียนโปรแกรมนอกเหนือจากรหัสที่ทำให้งงงวย

เหตุใดจึงต้องใช้สิ่งนี้ในภาษาการเขียนโปรแกรม

ปรับปรุง:

ดูเหมือนว่าคนที่คุณรู้ว่าทำคำสั่งเกี่ยวกับเรื่องนี้

ในขณะที่การพับเคสค่อนข้างเล็กน้อยในภาษาอังกฤษ แต่ในบางภาษาก็มีน้อยกว่ามาก หากโปรแกรมเมอร์ภาษาเยอรมันใช้ßในชื่อตัวแปรคุณจะพิจารณาอะไรเป็นตัวพิมพ์ใหญ่หรือเทียบเท่า เพียง FYI "SS" ถูกเท่านั้นที่เคยใช้ในกรณีที่ต่ำกว่า OTOH "เอสเอส" เป็นเทียบเท่า - คุณจะพิจารณาคอมไพเลอร์จำเป็นต้องตรงกับพวกเขา? เมื่อคุณเข้าสู่ Unicode คุณจะพบปัญหาที่น่าสนใจยิ่งขึ้นเช่นตัวละครที่มีเครื่องหมายกำกับการออกเสียงที่ประกอบไว้ล่วงหน้าและการแยกกำกับการออกเสียง ถ้าอย่างนั้นคุณก็มาที่สคริปต์ภาษาอารบิกโดยมีตัวอักษรจำนวนมากสามแบบแยกกันแทนที่จะเป็นสองแบบ

ในยุคมืดภาษาการเขียนโปรแกรมส่วนใหญ่ไม่คำนึงถึงขนาดตัวพิมพ์ ตัวอย่างเช่น Pascal เริ่มต้นจาก mainframes ของ Data Data ซึ่งใช้เพียงหกบิตต่อตัวอักษร (รวม 64 รหัส, ทั้งหมด) เครื่องส่วนใหญ่ใช้ชุดอักขระ "CDC Scientific" ซึ่งมีเฉพาะอักขระตัวพิมพ์ใหญ่เท่านั้น คุณสามารถเปลี่ยนเป็นชุดอักขระอื่น ๆ ได้ แต่ส่วนใหญ่มีทั้งตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก แต่ไม่ใช่ทั้งสองตัว - แต่ใช้รหัสเดียวกันทั้งคู่ สิ่งเดียวกันนั้นเป็นจริงของรหัส Baudot โบราณและมาตรฐานที่พิจารณาเช่นนี้ในวันเริ่มต้นของ COBOL, FORTRAN, BASIC ฯลฯ เมื่อถึงเวลาที่ฮาร์ดแวร์ที่มีความสามารถมากขึ้นก็มีให้ใช้กันอย่างกว้างขวาง .

เมื่อเวลาผ่านไปความยากของ case-insensitivity นั้นชัดเจนมากขึ้นและนักออกแบบภาษาส่วนใหญ่ตัดสินใจ ("ตระหนัก" อาจเป็นคำที่ถูกต้องมากกว่า) ว่าเมื่อ / หากผู้คนต้องการ case insensitivity จริง ๆ มันจัดการได้ดีขึ้นโดยเครื่องมือเสริม กว่าในภาษาเอง

อย่างน้อย IMO คอมไพเลอร์ควรป้อนข้อมูลให้ตรงตามที่เสนอไม่ใช่ตัดสินใจว่า "คุณเขียนสิ่งนี้ แต่ฉันจะถือว่าคุณหมายถึงอย่างอื่นจริง ๆ " หากคุณต้องการให้การแปลเกิดขึ้นคุณก็ควรแยกมันออกเป็นชิ้น ๆ ด้วยเครื่องมือที่ออกแบบมาเพื่อจัดการกับมัน

ทำไมทุกคนถึงต้องการความรู้สึกไม่รู้สึกตัว ในสถานการณ์ใดมันจะมีประโยชน์ที่จะสามารถอ้างถึงตัวแปรเดียวVARIABLEในสถานที่หนึ่งVariableในที่อื่นและvariableในหนึ่งในสาม? การไม่รู้สึกตัวตัวพิมพ์เล็กและใหญ่ ฉันค่อนข้างจะได้รับข้อผิดพลาดของคอมไพเลอร์เมื่อฉันพิมพ์โดยไม่ได้ตั้งใจVAriableแทนที่จะVariableปล่อยให้ตัวพิมพ์เล็กและใหญ่พิมพ์รหัสของฉัน

โดยสรุปภาษาการเขียนโปรแกรมจำนวนมากมีความไวตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ไม่เพียง แต่สำหรับเหตุผลทางประวัติศาสตร์ / แรงเฉื่อยเท่านั้น

ใน Java case sensitive ไม่ได้ใช้เพื่อให้ตัวเลือกเพิ่มเติมในรหัส แต่สำหรับความหมายที่ชัดเจนและสอดคล้องกันความหมาย ClassesLookLikeThis objectsLookLikeThis methodsLookLikeThis () STATIC_VARIABLES_LOOK_LIKE_THIS Classes.WithInnerClassesLookLikeThis มันไม่ได้ให้อิสระมากขึ้น: ช่วยให้คุณสามารถรวบรวมข้อมูลบางส่วนอย่างย่อในสิ่งที่เป็นภาษา verbose มากเกินไป

ฉันคิดว่าในภาษาที่พิมพ์แบบสแตติกอย่างชัดเจนด้วย mucho compiler และการสนับสนุน IDE ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เป็นวิธีที่ดีในการสื่อสารข้อมูล (เช่น Java) ด้วยภาษาอย่าง Ruby การใช้ตัวพิมพ์เล็กและตัวพิมพ์เล็กอาจทำให้ได้ผลลัพธ์ที่ไม่คาดคิดมากขึ้นถึงแม้ว่าฉันจะเปิดให้ลองใช้ตัวพิมพ์เล็กและตัวพิมพ์เล็กก็ตาม

ฉันคิดว่ากรณีที่ความไวกับระบบที่เข้มงวดไม่ได้ทำให้งงงวยรหัส แต่จริง ๆ แล้วทำให้ชัดเจนขึ้น พิจารณาโค้ด Java ที่เป็นไปได้:

      joe blah = new hUf();

ค่อนข้างชัดเจน แต่เกี่ยวกับ:

      hUf.WTF();

ใน Java ตามความเป็นจริงคุณจะรู้ว่านี่คืออะไรโดยอัตโนมัติ ในกรณีที่ไม่คำนึงถึง Java มันไม่ชัดเจนดังนั้นคุณต้องใช้กลไกอื่น ๆ เพื่อแยกคลาสออกจากอินสแตนซ์จากแพ็คเกจจากเมธอด และกลไกนั้นอาจทำให้คุณอาเจียนด้วยวิธีที่น่าเกลียด :)

ฉันไม่คิดว่ามันเป็น "การใช้งาน" มากเท่ากับ "อนุญาต" การพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เป็นสถานะเริ่มต้นของการเปรียบเทียบสตริง ใช้งานพิเศษสำหรับวิศวกรคอมไพเลอร์ในการสร้าง case case insensitive เนื่องจากคุณต้องเพิ่มโค้ดพิเศษเพื่อทำการเปรียบเทียบ case-insensitive และรักษาชื่อโทเค็นดั้งเดิมไว้เพื่อการรายงานข้อผิดพลาดและคำเตือนที่ถูกต้อง

เกือบจะแน่นอนว่าทำไมมันถึงลงเอยใน C; พวกเขาต้องการสร้างภาษาที่เรียบง่ายซึ่งใช้งานคอมไพเลอร์ได้ง่ายโดยเสียค่าใช้จ่ายในการใช้งาน ทำไมมันอยู่ใน langauges ทันสมัย? เพราะมันอยู่ใน C แน่นอนดังนั้นมันต้องเป็นวิธีที่ถูกต้องที่จะทำ! </ โหมดถากถาง>

หากไม่มีอะไรอื่นมันช่วยให้การแยกวิเคราะห์ง่ายขึ้นและช่วยให้คุณสามารถรวมชื่อตัวแปร / คลาสได้มากขึ้น

ด้วยการแยกวิเคราะห์ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่คุณจะถูก จำกัด ให้ใช้ตัวระบุเฉพาะเนื่องจาก 'myClass' และ 'MyClass' จะเป็นสิ่งเดียวกัน หรือคุณจะต้องเพิ่มเลเยอร์ของความซับซ้อนให้กับ parser ของคุณเพื่อให้แน่ใจว่าคุณสามารถกำหนดตัวระบุที่จะใช้ตามบริบท

พิจารณากรณีเช่นนี้:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

สมมติว่าคลาส XmlWriter มีวิธีการแบบคงที่ที่เรียกว่า "เขียน" คุณกำลังโทรหามันในอินสแตนซ์หรือคลาสถ้าไม่มีการใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ที่นี่

ฉันชอบความอ่อนไหวของตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หากไม่มีเหตุผลอื่นนอกจากจะทำให้การจัดทำเอกสารด้วยตนเองมากขึ้น:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

ฉันมักจะเขียนโปรแกรมใน Python แต่ใน C # วันของฉันฉันพบว่ามันสะดวกมากในการตั้งชื่ออินสแตนซ์ของคลาสเหมือนกับคลาส แต่เป็นกรณีที่ต่ำกว่า (หรืออูฐ) (ตามที่คนอื่นพูด):

Thing thing = new Thing();

การใช้ภาษาที่ไม่ต้องใช้ตัวพิมพ์เล็กและตัวใหญ่นั้นต้องใช้ระเบียบแบบแผนอื่นสำหรับเรื่องนี้เช่น sigil บางประเภทเช่น:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

ซึ่งเป็น "สิ่งเลวร้าย"

ฉันยังพบว่ามันสะดวกที่จะ grep (ตรงตามตัวพิมพ์ใหญ่ - เล็ก) เพื่อค้นหาการอ้างอิงถึง class และการใช้ตัวแปร ด้วยภาษาที่คำนึงถึงขนาดตัวพิมพ์นี่จะง่ายกว่า เหมือนกันสำหรับการค้นหาและแทนที่

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

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

ใช้ภาษาเป็นตัวอย่าง ทำไมเราถึงเริ่มประโยคและตั้งชื่อสิ่งของด้วยตัวพิมพ์ใหญ่ ... มันเป็นเพราะ unix ด้วยเหรอ?

ฉันคิดว่าสำหรับ lanaguages ​​ที่พิมพ์แบบคงที่เช่น C # และ Java มันไม่ได้เพิ่มคุณค่าใด ๆ เพราะในกรณีส่วนใหญ่คุณมี IDE ที่จะแก้ไขกรณีและปัญหาที่ไม่ตรงกันให้คุณโดยอัตโนมัติดังนั้นในตอนท้ายของวันถ้าฉันพิมพ์ "VAriable" โดยไม่ตั้งใจ IDE ของฉันจะแก้ไขโดยอัตโนมัติให้เป็น " ตัวแปร "สำหรับฉัน เพิ่มไปที่การMyClass myClass;ประชุมสไตล์และคุณจะเห็นว่าการพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่นั้นไม่จำเป็นต้องเป็นสิ่งที่ไม่ดี

สำหรับภาษาที่พิมพ์แบบไดนามิกอาจมีการโต้แย้งมากกว่าเนื่องจาก IDE ยากที่จะเดาการแก้ไขอัตโนมัติ แต่ในกรณีของภาษาที่พิมพ์แบบไดนามิกคุณจะมีความกังวลมากขึ้น (ในแง่ของ typos) ที่ใช้แบบแผนเคสที่สอดคล้องกันจะไม่เพิ่มภาระที่มากขึ้น

ใช่แล้วในขณะที่ไม่มีภาษาเหตุผลที่แท้จริงไม่อาจไม่ตรงตามตัวพิมพ์ใหญ่ - เล็ก แต่ก็ไม่มีเหตุผลที่แท้จริงว่าทำไมพวกเขาควรเป็นเช่นนั้น

บทความจาก Scott Hanselman เกี่ยวกับ "SignOn" กับ "Signon" นั้นเกี่ยวกับการเปรียบเทียบสตริงและไม่มีอะไรเกี่ยวข้องกับภาษาการเขียนโปรแกรม ฉันยอมรับว่าสตริงที่ผู้ใช้พิมพ์ควรเปรียบเทียบแบบตัวพิมพ์ใหญ่ - เล็กเสมอ แต่ฉันคิดว่านั่นเป็น ballgame ที่แตกต่างจากตัวระบุในภาษาการเขียนโปรแกรม

เมื่อภาษาเป็นกรณี ๆ ไปฉันจะใช้ประโยชน์จากภาษานั้นเพื่อสร้างการใช้งานเคสแบบเดิมในคณิตศาสตร์และวิทยาศาสตร์ นี่คือรายการ (โดยไม่ละเอียด) ของการประชุมบางกรณี:

• ในทฤษฎีความน่าจะเป็นตัวพิมพ์เล็กfมักแสดงฟังก์ชันความหนาแน่นของความน่าจะเป็น (pdf) ในขณะที่ตัวพิมพ์ใหญ่Fแสดงถึงฟังก์ชันการแจกแจงสะสมที่สอดคล้องกัน (cdf)
• ในทฤษฎีความน่าจะเป็นตัวอักษรตัวพิมพ์ใหญ่แสดงถึงตัวแปรแบบสุ่มXและตัวอักษรตัวพิมพ์เล็กที่สอดคล้องกันแสดงถึงการรับรู้ของพวกเขาxเช่นเดียวกับใน $ Pr [X = x] \ leq 0.05 $
• ในพีชคณิตเชิงเส้นตัวอักษรตัวพิมพ์ใหญ่มักใช้เพื่ออ้างถึงเมทริกซ์ในขณะที่ตัวอักษรตัวพิมพ์เล็กมักจะใช้เพื่ออ้างถึงตัวเลขเช่น $ A = [a_ {ij}] $
• สัญลักษณ์หน่วยถูกเขียนด้วยตัวอักษรตัวพิมพ์เล็ก (เช่น m สำหรับเมตร) ยกเว้นลิตร (L) และหน่วยที่ได้มาจากชื่อของบุคคล (W สำหรับวัตต์, Pa สำหรับ Pascal, N สำหรับนิวตันและอื่น ๆ )
• สัญลักษณ์ของคำนำหน้าหมายถึงหนึ่งล้านหรือมากกว่านั้นเป็นตัวพิมพ์ใหญ่ (M สำหรับ mega (ล้าน)) และที่น้อยกว่าหนึ่งล้านเป็นตัวพิมพ์เล็ก (m สำหรับหนึ่งในพัน (หนึ่งในพัน))

ฉันเพิ่งคิดว่ามันเป็นเพราะยูนิกซ์และซี - แต่นั่นเป็นปัญหาไก่และไข่ซึ่งมีเพียงคนแก่เท่านั้นที่สามารถตอบได้อย่างถูกต้อง

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

อาจมีการเชื่อมโยงระหว่างเครื่องหมายปีกกาหยิกและความไวของกรณีเช่นกัน

นอกจากคำตอบที่ยอดเยี่ยมที่ให้มาจนถึงตอนนี้ฉันต้องการที่จะชี้ให้เห็นว่าการตอบสนองของกรณีให้คุณ "namespaces" เพิ่มเติม ยกตัวอย่างเช่น Perl มีบล็อคพิเศษบางอย่างBEGINและENDที่ทำงานในเวลาที่แตกต่างจากรหัสปกติ (BEGIN ณ เวลารวบรวม, สิ้นสุดหลังจากโปรแกรมปกติสิ้นสุด) และการที่บล็อกทั้งหมดทำให้พวกเขาโดดเด่นและหมายความว่ากรณีที่ต่ำกว่า ตัวแปรไม่ใช่คำที่สงวนไว้

หนึ่งสามารถไปได้มากขึ้นและจองชื่อตัวพิมพ์ใหญ่ทั้งหมดสำหรับการใช้งานในอนาคตโดยภาษาและไม่ทำอันตรายใด ๆ กับโปรแกรมเมอร์ปกติซึ่งมักจะไม่ควรใส่รหัสของพวกเขา

"การพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่" จะดีกว่าสำหรับบุคคลด้านเทคนิคเพื่อลดความกำกวม ใช้ชื่อไฟล์เป็นตัวอย่าง การจัดการกับชื่อไฟล์ของ Windows เป็นปัญหามากกว่าชื่อไฟล์ Unix เนื่องจากชื่อไฟล์ใน Windows จะไม่ตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็กในขณะที่ชื่อไฟล์ใน Unix จะคำนึงถึงขนาดตัวพิมพ์

กลับไปที่การเขียนโปรแกรม สำหรับชื่อคลาสชื่อเมธอดชื่อตัวแปรภาษาส่วนใหญ่ไม่บังคับใช้กฎลักษณะการตั้งชื่อ บางครั้งเพื่อความเรียบง่ายในการทำ "การสะท้อน" เราสามารถใช้ชื่อ "Case sensitive" เพื่อผูกกับแหล่งข้อมูลอื่นโดยไม่ต้องแปลงหรือจัดการปัญหาของชื่อเดียวกัน แต่ในกรณีอื่น

ฉันประหลาดใจกับคำพูดนี้ ตอนนี้ไม่มีใครต้องการให้คุณใช้เครื่องหมายขีดเส้นใต้หรือm_ในชื่อเขตข้อมูลใน C # ฉันเพิ่งใช้กรณีอูฐและถ้าชื่อเขตข้อมูลเหมือนกับชื่อทรัพย์สินสาธารณะเพียงว่าชื่อทรัพย์สินสาธารณะเป็นกรณี Pascal และเขตข้อมูลสำรองเป็นกรณีอูฐฉันคิดว่า "ดังนั้นไม่ว่า" - นั่นคือสิ่งที่ชุมชนการเขียนโปรแกรมที่มีขนาดใหญ่ดูเหมือนว่าต้องการ มันไม่ได้ทำให้เกิดปัญหาใด ๆ

โดยเฉพาะโปรแกรมเมอร์บางคนมาจากยุคแรก ๆ ของ BASIC ซึ่งชื่อตัวแปรสามารถมีความยาวได้เพียง 2 ตัวอักษร

ดังนั้นเมื่อมันสามารถเป็นตัวละครได้ไม่กี่ตัวพวกเขาก็มีความสุขมาก และพร้อมกับความไวของตัวพิมพ์เล็ก - เพราะพวกเขาไม่ต้องการที่จะสนใจSomeNameว่าจะเท่ากันโดยไม่ตั้งใจSOMENAMEและทำให้เกิดข้อผิดพลาดเนื่องจากสิ่งต่าง ๆ เช่นนี้