คำหลักที่ไม่ตรงตามตัวพิมพ์ใหญ่และเล็กในภาษา [ปิด]

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

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

นี่เป็นความคิดที่ดีหรือไม่?

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

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

อีกครั้งนี่ไม่ใช่ตัวเลือกด้านเทคนิค เป็นตัวเลือกการจัดการผลิตภัณฑ์ที่ต้องทำโดยคนที่รู้จักกลุ่มเป้าหมายได้ดี

คุณควรตัดสินใจตามประสบการณ์ของผู้ใช้ที่คุณต้องการนำเสนอไม่ใช่ว่าจะนำไปใช้ง่ายหรือยากเพียงใด

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

เป็นกรณีในจุด SQL เป็นกรณีตาย สิ่งนี้ทำให้ง่ายต่อการใช้งานในการตั้งค่าแบบโต้ตอบ

อีกวิธีในการดูสิ่งนี้คือจะมีความแตกต่างระหว่างkeywordและKeywordในภาษาของคุณและความแตกต่างนี้จะมีความหมายกับผู้ใช้หรือไม่ สำหรับภาษาสคริปต์ฉันจะบอกว่าคำตอบคือ "ไม่"

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

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

ในขณะที่มันเป็นเรื่องธรรมดาที่จะทำเคสพับในอาคาร หากเทอร์มินัลสามารถแสดงตัวพิมพ์ใหญ่เท่านั้น แต่คุณต้องเข้าสู่ระบบคอมพิวเตอร์ที่รองรับตัวพิมพ์ใหญ่และตัวเล็กเครื่องจะพับตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ คิดว่านานแล้วเหรอ? "เช่นเดียวกับ Apple II Apple II Plus ไม่มีฟังก์ชั่นตัวพิมพ์เล็ก" (http://en.wikipedia.org/wiki/Apple_II_Plus) เมื่อผู้ใช้คอมพิวเตอร์ Apple รุ่นแรกโทรเข้าสู่ BBS ที่มีเนื้อหาแบบตัวพิมพ์ผสมเทอร์มินัลอีมูเลเตอร์ (หรือโฮสต์) ต้องพับตัวพิมพ์ใหญ่และตัวพิมพ์ใหญ่ทั้งหมด ข้อความที่เขียนในตัวพิมพ์ใหญ่ทั้งหมดเป็นเรื่องธรรมดาบนกระดานข่าวในสมัยนั้น ฟังก์ชั่นนี้ยังคงพบในระบบปฏิบัติการยูนิกซ์เช่น Linux kernel ตัวอย่างเช่นพิมพ์stty olcucที่พร้อมต์เชลล์ของคุณวินัย Unix tty line สามารถแม็พตัวพิมพ์เล็กและตัวใหญ่บนเอาต์พุตและแม็พตัวพิมพ์ใหญ่เพื่อลดอินพุต สิ่งนี้ช่วยให้คุณสามารถทำงานในภาษาการเขียนโปรแกรมตัวพิมพ์เล็กบนเทอร์มินัลที่ไม่มีตัวพิมพ์เล็ก

Case insensitivity เป็นแนวคิดที่ล้าสมัยจากยุคคอมพิวเตอร์ในอดีตที่ไม่สามารถทำงานได้ดีนักในโลกยุคใหม่ของการคำนวณแบบสากล คุณขยายออกไปเป็นภาษาอื่น ๆ หรือไม่? แล้วภาษาฝรั่งเศสคุณคิดว่าÈและèเท่ากันหรือไม่? หรือญี่ปุ่น คุณคิดว่าฮิระงะนะและคาตาคานะเป็นเพียงตัวเล็ก ๆ เท่านั้นดังนั้น so that イルและふぁいるเป็นตัวระบุเดียวกันหรือไม่ การสนับสนุนความเขลาดังกล่าวจะทำให้ตัววิเคราะห์คำของคุณซับซ้อนขึ้นอย่างมากซึ่งจะต้องมีการแมปการเทียบเคียงกรณีสำหรับพื้นที่ Unicode ทั้งหมด

โปรดทราบว่าคณิตศาสตร์เป็นกรณี ๆ ไป ตัวอย่างเช่น sigma ตัวพิมพ์ใหญ่อาจแสดงถึงการรวมในขณะที่ซิกมาตัวพิมพ์เล็กหมายถึงสิ่งอื่นเช่นค่าเบี่ยงเบนมาตรฐาน สิ่งนี้สามารถเกิดขึ้นได้ในสูตรเดียวกันโดยไม่ต้องสร้างปัญหาใด ๆ (ภาษาการเขียนโปรแกรมจะทำให้Σและσเทียบเท่าหรือไม่)

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

Basicaly ภาษาการเขียนโปรแกรมใหม่ใด ๆ ที่สร้างขึ้นตั้งแต่ปี 1985 ซึ่งไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่สำหรับผู้ที่ยังคงต้องใช้ E-MAILS และการโพสต์

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

ดูปัญหาที่น่ารำคาญที่เกิดจากการจัดการเคสใน Windows เมื่อไฟล์ถูกนำเข้าจากระบบปฏิบัติการอื่น นั่นเป็นปัญหาทางเทคนิค ระบบไฟล์ที่มีตัวอักษรตัวพิมพ์เล็กและใหญ่มีปัญหากับข้อมูลต่างประเทศซึ่งตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ไม่ได้

Common Lisp ใช้วิธีการในอุดมคติ: ชื่อสัญลักษณ์จะต้องตรงตามตัวพิมพ์เล็กและใหญ่ แต่เมื่อมีการอ่านโทเค็น ซึ่งหมายความว่าสัญญาณfoo, fOO, FOOและแสดงว่าทุกสัญลักษณ์เดียวกันสัญลักษณ์ที่มีชื่อจะถูกเก็บไว้เป็นสตริงตัวอักษรFoo "FOO"นอกจากนี้พฤติกรรมนี้เป็นเพียงการกำหนดค่าตารางการอ่านเริ่มต้น ผู้อ่านสามารถพับตัวอักษรไปที่ตัวพิมพ์ใหญ่เพื่อตัวพิมพ์เล็กกลับหัวกลับด้านหรือเก็บรักษาไว้ สองตัวเลือกสุดท้ายก่อให้เกิดภาษาถิ่น วิธีนี้ผู้ใช้มีความยืดหยุ่นสูงสุด

ปัจจัยกำหนดที่แท้จริงคือความถี่ที่คุณต้องการมีหลายสิ่งด้วยชื่อเดียวกัน Case insensitivity ทำงานใน SQL เพราะคุณไม่ต้องการคอลัมน์ชื่อSELECTบ่อย มันจะน่ารำคาญใน Java เพราะทุก ๆ บรรทัดดูเหมือนว่าObject object = new Object()ที่คุณต้องการชื่อเดียวกันเพื่ออ้างถึงคลาสอินสแตนซ์และตัวสร้าง

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

ฉันสร้างภาษากฎขึ้นมาเมื่อตัวระบุไม่เพียงแค่ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เท่านั้น ฉันอนุญาตให้สร้างนามแฝงที่อ้างถึงตัวระบุเดียวกัน ตัวอย่างเช่น ProgrammersStackExchange, โปรแกรมเมอร์แลกเปลี่ยนกองซ้อนและ PSE ทั้งหมดแก้ไขเป็นสัญลักษณ์เดียวกันแน่นอนและสามารถใช้แทนกันได้

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

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

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

ATypo = 42; 

ตรงข้ามกับ

Atypo = 42; 

ไม่จำเป็นต้องขอเวลาแก้ไขข้อบกพร่องเมื่อมีสองคำสั่งที่เทียบเท่าทำให้ชีวิตง่ายขึ้น

ตัวอย่างของภาษาเช่น FORTRAN, BASIC, SQL นั้นถูกระบุว่าเป็นตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

เหตุผลที่ FORTRAN และ SQL (และ COBOL) ไม่ตรงตามตัวพิมพ์ใหญ่และตัวพิมพ์เล็กคือสิ่งเหล่านั้นถูกออกแบบมาเพื่อใช้กับเครื่องที่ชุดอักขระปกติมีตัวอักษรตัวพิมพ์ใหญ่เท่านั้น การไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ในภาษาเหล่านั้น (อย่างน้อย) เป็นสิ่งประดิษฐ์ทางประวัติศาสตร์มากกว่าตัวเลือกการออกแบบภาษา

ตอนนี้คุณสามารถโต้แย้งกรณีที่ไม่มีความรู้สึกของการให้อภัยมากขึ้น แต่ด้านพลิกเป็นกรณีที่ความไวผลในรหัสที่อ่านได้มากขึ้นเพราะมันเป็นเรื่องง่ายต่อการใช้งานของคุณในขณะที่ cApItAlIzAtIoN

ความไวของคดีถือว่าเป็นอันตราย

ชีวิตไม่คำนึงถึงขนาดตัวพิมพ์และไม่เป็นผู้ใช้หรือโปรแกรมเมอร์

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

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

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

จากประสบการณ์ส่วนตัวของฉันฉันไม่เห็นความแตกต่างใหญ่ระหว่างภาษาที่เล็กและใหญ่และเล็ก

สิ่งสำคัญคือการตั้งชื่อและอนุสัญญาโครงสร้างที่โปรแกรมเมอร์ควรเก็บไว้ในรหัสของเขาและไม่มีคอมไพเลอร์หรือ parser ตรวจสอบให้เขา ถ้าคุณยึดติดกับกฎบางอย่างคุณจะรู้ชื่อที่ถูกต้องได้ง่าย (คุณจะไม่คิดว่าคุณตั้งชื่อตัวแปร checkOut หรือ CheckOut) และรหัสของคุณอาจต้องตรงตามตัวพิมพ์ใหญ่และง่ายต่อการอ่าน

หนึ่งไม่ควรใช้ CheckOut และ checkOut และ checkout และ cHeCkOuT และ CHECKOUT ในความหมายเดียวกัน มันจะสร้างความเสียหายให้กับการอ่านและทำให้เข้าใจว่ารหัสนั้นมีความเจ็บปวดมากขึ้น (แต่มีสิ่งที่แย่กว่านั้นที่เราสามารถทำได้เพื่อทำลายการอ่านของโค้ด)

หากคุณใช้กฎบางประเภทคุณจะเห็นตัวอย่าง:

CheckOut.getInstance () - เป็นวิธีการคงที่ของคลาสที่เรียกว่า checkOut.calculate () - เป็นวิธีการของวัตถุที่เก็บไว้ในตัวแปรหรือเขตข้อมูลสาธารณะที่เรียกว่า _checkOut.calculate () - มันเป็นวิธีการของวัตถุที่เก็บไว้ในเขตข้อมูลส่วนตัวที่เรียกว่า CHECKOUT - เป็นฟิลด์ / ตัวแปรสุดท้ายแบบคงที่หรือคงที่

โดยไม่ต้องตรวจสอบไฟล์อื่น ๆ หรือบางส่วนของไฟล์ ทำให้การอ่านรหัสเร็วขึ้น

ฉันเห็นนักพัฒนาซอฟต์แวร์จำนวนมากที่ใช้กฎที่คล้ายกัน - ในภาษาที่ฉันมักใช้: Java, PHP, Action Script, JavaScript, C ++

ในกรณีที่เกิดขึ้นได้ยากผู้ใช้อาจรู้สึกโกรธในกรณีที่ไม่มีความรู้สึกตัวพิมพ์เล็ก - ตัวอย่างเช่นเมื่อต้องการใช้ CheckOut สำหรับชื่อคลาสและ checkOut สำหรับตัวแปรและไม่สามารถทำได้เพราะมันขัดแย้งกัน แต่มันเป็นปัญหาของโปรแกรมเมอร์ที่ใช้ในการพิจารณาตัวพิมพ์เล็กและใช้ในแบบแผนการตั้งชื่อของเขา หนึ่งสามารถมีกฎกับคำนำหน้ามาตรฐานหรือ postfixes ในภาษาตายกรณี (ฉันไม่ได้เขียนโปรแกรมใน VB แต่ฉันรู้ว่าโปรแกรมเมอร์ VB หลายคนมีแบบแผนการตั้งชื่อเช่นนี้)

ในคำไม่กี่คำ: ฉันเห็นว่าตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ดีกว่า (สำหรับภาษาเชิงวัตถุเท่านั้น) เพราะนักพัฒนาส่วนใหญ่ใช้ภาษาที่คำนึงถึงขนาดตัวพิมพ์และส่วนใหญ่ใช้แบบแผนการตั้งชื่อตามความไวของตัวพิมพ์เล็กดังนั้นพวกเขาต้องการภาษา สามารถติดกฎของพวกเขาได้โดยไม่ต้องดัดแปลงอะไรเลย แต่มันก็เป็นข้อโต้แย้งทางศาสนา - ไม่ใช่วัตถุประสงค์ (ไม่ได้ขึ้นอยู่กับข้อเสียเปรียบจริงหรือแง่มุมที่มีความอ่อนไหวของคดี - เพราะฉันไม่เห็นเลยเมื่อมันมาถึงผู้พัฒนาที่ดีเมื่อพูดถึง bAd DeVeLoPeR คนหนึ่ง แม้ในกรณีที่มีความอ่อนไหวดังนั้นมันจึงไม่แตกต่างกันมากนัก)

ภาษาการเขียนโปรแกรมควรคำนึงถึงขนาดตัวพิมพ์

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

นี่เป็นส่วนหนึ่งของปรัชญาการขับขี่ที่อยู่เบื้องหลัง C และ UNIX: หากคุณมีตัวเลือกระหว่างโซลูชันที่ไม่ดีที่ใช้งานง่ายและโซลูชันที่ดีที่ยากต่อการใช้งานให้เลือกโซลูชันที่ไม่ดีและผลักภาระการทำงานของคุณออกไป ผู้ใช้งาน. นี่อาจฟังดูน่ากลัว แต่มันเป็นเรื่องจริง เป็นที่รู้จักกันดีในนาม "แย่กว่าหลักการที่ดีกว่า" และรับผิดชอบโดยตรงต่อความเสียหายหลายพันล้านดอลลาร์ในช่วงสองสามทศวรรษที่ผ่านมาเนื่องจาก C และ C ++ ทำให้การเขียนซอฟต์แวร์ที่ผิดพลาดและไม่ปลอดภัยนั้นง่ายเกินไป

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

• ขั้นแรกโดยเฉพาะถ้าคุณกำลังสร้างภาษาสคริปต์ตัวพิมพ์แบบง่าย ๆ ที่คุณเรียกบางสิ่งบางอย่าง "myObject" ในที่เดียวและ "MyObject" ในที่อื่นซึ่งเห็นได้ชัดว่าคุณอ้างถึงวัตถุเดียวกัน แต่เพิ่งขัดแย้งกับตัวพิมพ์ใหญ่เล็กน้อย อย่าเปลี่ยนเป็นข้อผิดพลาดรันไทม์ (นี่เป็นจุดอ่อนที่สำคัญในภาษาสคริปต์ที่ทำให้เกิดข้อผิดพลาดเช่น Python)
• ประการที่สองการไม่มีความอ่อนไหวของกรณีหมายถึงการไม่คำนึงถึงขนาดตัวพิมพ์เล็กและใหญ่ที่มีคำเดียวกันหมายถึงสิ่งที่แตกต่างกันสองอย่างในขอบเขตเดียวกันเพียงแค่เปลี่ยนการใช้อักษรตัวพิมพ์ใหญ่ หากคุณเคยทำงานกับรหัส Windows ในสภาพแวดล้อม C และทำงานในการประกาศที่น่าเกลียดเช่นHWND hwnd;คุณจะรู้ว่าสิ่งที่ฉันพูดถึง ผู้ที่เขียนเช่น oughtta นั้นจะถูกนำออกมาและยิงและการทำให้ตัวพิมพ์เล็กและตัวพิมพ์เล็กภาษาไม่สามารถป้องกันการใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ในโค้ดของคุณ

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

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

แน่นอนที่สุดมันไม่ได้! ฉันได้ดูไหล่ของเพื่อนร่วมงานในตัวแปรที่เรียกว่า บริษัท และ บริษัท (บริษัท ตัวแปรสาธารณะจับคู่ บริษัท ตัวแปรส่วนตัว) และการเลือกแบบอักษรและสีของเขาทำให้มันยากที่จะบอกความแตกต่างระหว่างทั้งสอง - อย่างไม่น่าเชื่อ

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

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

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

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

ยิ่งไปกว่านั้นให้ใช้การประชุมที่ตัวแปรภาคเอกชนรบกวนปัจจัยต่อไปเช่นตัวแปรสาธารณะของ บริษัท ตัวแปร CompanyP ไม่มีใครจะไปรวมกันทั้งสองโดยไม่ได้ตั้งใจและพวกเขาปรากฏตัวพร้อมกันใน Intellisense

สิ่งนี้ตรงกันข้ามกับการคัดค้านของคนที่มีต่อสัญกรณ์ฮังการีซึ่ง pCompany ตัวแปรส่วนบุคคลที่ขึ้นต้นแล้วจะไม่ปรากฏในตำแหน่งที่ดีใน intellisesne

การประชุมนี้มีข้อดีทั้งหมดของการประชุมกรณีบน / ล่างที่น่ากลัวและไม่มีข้อเสีย

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

ทำสิ่งที่คุณทำงานด้วยความชัดเจนและแตกต่างซึ่งกันและกันแม้ว่าพวกมันจะเกี่ยวข้องกัน !!

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

โปรแกรมเมอร์ในยุคนี้คาดว่าความไวของเคส

การพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ทำให้โค้ดอ่านง่ายขึ้นและการเขียนโปรแกรมง่ายขึ้น

• คนพบว่าการใช้งานที่เหมาะสมของกรณีผสมให้อ่านง่ายขึ้น

• จะช่วยให้ / ส่งเสริมให้ CamelCase ดังกล่าวว่าคำเดียวกันกับกรณีที่แตกต่างกันสามารถอ้างถึงสิ่งที่เกี่ยวข้องกันCar car; ดังนั้นตัวแปรที่มีชื่อจะถูกสร้างขึ้นจากประเภทcarCar

• ALL_CAPS_WITH_UNDERSCORES บ่งชี้ว่าค่าคงที่ตามการประชุมในหลายภาษา

• all_lower_with_underscores สามารถใช้สำหรับตัวแปรสมาชิกหรืออย่างอื่น

• เครื่องมือการเขียนโปรแกรมที่ทันสมัยทั้งหมด (การควบคุมแหล่ง, บรรณาธิการ, diff, grep และอื่น ๆ ) ได้รับการออกแบบเพื่อให้ตรงตามตัวพิมพ์ใหญ่และเล็ก คุณจะมีปัญหากับเครื่องมือที่โปรแกรมเมอร์ใช้หากไม่ได้รับอนุญาต

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

• แล้วตัวละครที่ไม่ใช่ภาษาอังกฤษล่ะ? คุณกำลังตัดสินใจที่จะไม่สนับสนุน Coptic, Chinese และ Hindi หรือไม่? ฉันขอแนะนำอย่างยิ่งให้คุณตั้งค่าภาษาเป็นค่าเริ่มต้นทุกอย่างเป็น UTF-8 และรองรับบางภาษาที่มีตัวอักษรที่ไม่มีตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก คุณจะไม่ใช้อักขระเหล่านี้ในคำหลักของคุณ แต่เมื่อคุณเริ่มปิดการใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ในเครื่องมือต่าง ๆ (เพื่อค้นหาสิ่งต่าง ๆ ในไฟล์) คุณจะพบกับประสบการณ์ที่เหนือจริงและไม่พึงประสงค์

ประโยชน์คืออะไร 3 ภาษาที่คุณพูดถึงนั้นมาจากปี 1970 หรือก่อนหน้า ไม่มีภาษาสมัยใหม่ทำเช่นนี้

ในทางกลับกันสิ่งใดก็ตามที่ทำให้ผู้ใช้ปลายทางมีความสุขจะนำแสงสว่างมาสู่โลก ถ้ามันจะส่งผลต่อความสุขของผู้ใช้จริงๆคุณก็ต้องทำ

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