ภาษาการเขียนโปรแกรมควรเข้มงวดหรือไม่ [ปิด]

ใน Python และ JavaScript เซมิโคลอนเป็นทางเลือก

ใน PHP เครื่องหมายคำพูดรอบ ๆ คีย์อาร์เรย์เป็นตัวเลือก ( $_GET[key]vs $_GET['key']) แม้ว่าคุณจะไม่ใส่มันก็ตามมันจะค้นหาค่าคงที่ด้วยชื่อนั้นก่อน นอกจากนี้ยังอนุญาตให้มีลักษณะที่แตกต่างกัน 2 แบบสำหรับบล็อก (เครื่องหมายโคลอนหรือตัวคั่นรั้ง)

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

คุณคิดอย่างไร?

โอเคภาษาของฉันไม่ได้เป็นภาษาการเขียนโปรแกรมเป็นภาษาเทมเพล ชนิดของการข้ามระหว่างHamlและDjango แม่ หมายถึงจะใช้กับ C # เว็บเฟรมเวิร์กของฉันและควรจะขยายได้มาก

ภาษาที่แตกต่างกันมีการใช้ที่แตกต่างกันดังนั้นคำตอบสำหรับคำถามนี้ขึ้นอยู่กับว่าคุณจะใช้ภาษาอะไร

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

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

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

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

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

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

ทุกที่ที่มีความกำกวมคอมไพเลอร์จำเป็นต้องมีวิธีที่จะคาดเดาสิ่งที่โปรแกรมเมอร์จริงๆหมายถึง ทุกครั้งที่สิ่งนี้เกิดขึ้นมีโอกาสที่โปรแกรมเมอร์จะหมายถึงสิ่งที่แตกต่างกัน แต่ไม่มีกฎการแก้ปัญหาความกำกวม

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

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

คำตอบว่าคุณควรทำให้ภาษาของคุณหลวมเท่ากับคำตอบของคำถามที่พูดในสำเนียงเท็กซัส "โชคดีที่คุณรู้สึกพังค์?"

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

การตั้งค่าส่วนตัวของฉันคือความสามารถในการมีความเข้มงวดเพียงพอที่จะตรวจจับความผิดพลาดของฉัน ฉันพูดคุยเกี่ยวกับปัญหานี้ได้ที่http://www.perlmonks.org/?node_id=755790 http://www.perlmonks.org/?node_id=755790

ที่กล่าวว่าคุณกำลังออกแบบภาษาของคุณเอง คุณควรทำให้มันเป็นอย่างที่คุณต้องการ

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

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

พูดตามตรงฉันจะลองใช้ภาษาต่างๆเพื่อดูว่าพวกเขาทำอะไรและพยายามหาช่องที่ไม่มีคนกดปุ่ม!

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

โชคดี.

ฉันขอแนะนำว่าภาษาการเขียนโปรแกรมที่ดีควรมีกฎที่เข้มงวดซึ่งคาดว่าการใช้งานจะบังคับใช้อย่างสม่ำเสมอ แต่กฎควรจะเขียนในลักษณะดังกล่าวเพื่อให้เป็นประโยชน์ ฉันขอแนะนำเพิ่มเติมว่าควรพิจารณาการออกแบบภาษาเพื่อหลีกเลี่ยงกรณีที่ "ระยะทาง Hamming" ระหว่างสองโปรแกรมที่แตกต่างกันอย่างมีนัยสำคัญเป็นเพียงหนึ่งเดียว เห็นได้ชัดว่าไม่มีใครสามารถบรรลุสิ่งนี้ด้วยตัวเลขหรือสตริงตัวอักษร (ถ้าโปรแกรมเมอร์ที่หมายถึง 123 แทนประเภท 1223 หรือ 13, คอมไพเลอร์ไม่สามารถรู้ได้อย่างชัดเจนว่าโปรแกรมนั้นหมายถึงอะไร) ในทางกลับกันหากใช้ภาษาในการ:=มอบหมายและ==เพื่อเปรียบเทียบความเท่าเทียมกันและไม่ใช้ภาษาใดภาษาหนึ่ง= สำหรับวัตถุประสงค์ทางกฎหมายใด ๆ จากนั้นจะลดความเป็นไปได้อย่างมากทั้งสำหรับการมอบหมายโดยไม่ตั้งใจซึ่งควรจะเป็นการเปรียบเทียบและการเปรียบเทียบโดยไม่ทำอะไรเลยโดยไม่ตั้งใจซึ่งควรจะเป็นการมอบหมาย

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

  พจนานุกรม <complexType1, complexType2> item =
    ใหม่พจนานุกรม <complexType1, complexType2 ()>;

กับ

  รายการ var = พจนานุกรมใหม่ <complexType1, complexType2 ()>;

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

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

สำหรับฉันการอ่านเป็นสิ่งสำคัญที่สุด

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

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

นอกจากไวยากรณ์แล้วภาษาควรมีความหมายที่ชัดเจนและบางทีอาจจะยากกว่าการตัดสินใจเลือกไวยากรณ์ที่เหมาะสม ...

ตัวอย่างที่ดี:

• ใน Java, "1"คือสตริง, 1เป็น int, 1.0เป็น double และ1Lยาว ลองมองดูแล้วคุณจะรู้ว่ามันคืออะไร

• ใน Java =คือการมอบหมาย มันกำหนดค่าสำหรับประเภทดั้งเดิมและการอ้างอิงสำหรับประเภทการอ้างอิง ไม่เคยคัดลอกข้อมูลที่ซับซ้อนหรือเปรียบเทียบ

• ใน Java การเรียกใช้เมธอดจำเป็นต้องใช้วงเล็บและวิธีนี้แตกต่างอย่างชัดเจนจากตัวแปรดังนั้นถ้าไม่มีวงเล็บคุณไม่จำเป็นต้องค้นหานิยามเมธอดมันเป็นเพียงการอ่านข้อมูล

ตัวอย่างที่ไม่ดี:

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

• ใน Java จุด.มีการใช้งานมากเกินไป สามารถเป็นตัวคั่นภายในชื่อแพ็กเกจตัวคั่นระหว่างแพ็กเกจและคลาสตัวคั่นระหว่างคลาสภายนอกและชั้นในตัวเชื่อมต่อระหว่างนิพจน์อินสแตนซ์และเมธอดที่จะเรียกใช้บนอินสแตนซ์และอื่น ๆ อีกมากมาย

• ในหลายภาษาวงเล็บปีกกาของifบล็อกเป็นทางเลือกซึ่งนำไปสู่ข้อผิดพลาดที่น่ารังเกียจหากมีคนเพิ่มคำสั่งอีกหนึ่งคำในบล็อก (ไม่มีอยู่จริง)

• ตัวดำเนินการมัด: บางครั้งฉันต้องหยุดที่นิพจน์เชิงตัวเลขและคิดอย่างหนักว่ามันหมายถึงอะไรทีละขั้นตอน a * b / c * d + eเราทุกคนใช้ในการแสดงออกเขียนคณิตศาสตร์ในสัญกรณ์มัดเช่น เวลาส่วนใหญ่เราจำลำดับความสำคัญของการคูณและการหารเหนือการบวกและการลบ (แต่คุณรู้หรือไม่ว่าเราไม่หารด้วยc*dแต่หารด้วยcแล้วคูณด้วยd?) แต่มีผู้ให้บริการมัดเพิ่มเติมจำนวนมากที่มีกฎสำคัญของตนเองและในบางภาษามีการใช้งานมากจนยากที่จะติดตาม การบังคับใช้วงเล็บอาจเป็นวิธีที่ดีกว่า ...

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