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

จากนั้นอีกครั้งคุณสามารถเขียนโค้ดที่ไม่ดีเหมือนเมื่อก่อนเพราะคุณไม่สนใจ แต่ความคิดเห็นของคุณคืออะไร

ฉันคิดว่าโปรแกรมเมอร์จะคิดวิธีอื่นในการเพิ่มความคิดเห็น ...

string aComment = "This is a kludge.";

ฉันไม่คิดว่ามันง่ายขนาดนั้น:

แม้ในรหัสที่ดีเป็นลายลักษณ์อักษร แต่ก็มีสถานการณ์ที่ถูกกฎหมายที่คุณควรเขียนความคิดเห็น

สมมติว่าคุณเป็นโปรแกรมเมอร์ที่สมบูรณ์แบบ (ซึ่งคุณไม่ได้ แต่ลองสมมุติ) ...

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

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

ไม่มีสิ่งใดทดแทนการพัฒนาที่ดี

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

ในขณะที่การลบความคิดเห็นอาจจะบังคับให้นักพัฒนาบางส่วนที่จะเขียนโค้ดที่ดีเอกสารด้วยตนเองยังคงมีนักพัฒนาออกมีการเขียนรหัสที่เอกสารไม่ดี (เช่นชื่อตัวแปรของa, b, cฯลฯ ) และมันก็เป็นนิสัยที่คนต้องได้รับการอบรมจาก จากของ ในกรณีดังกล่าวการลบความคิดเห็นจะไม่ส่งผลกระทบต่อนักพัฒนาเหล่านั้นและอาจขัดขวางความพยายามของผู้พัฒนารายอื่นในการอธิบายรหัสที่ซับซ้อน

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

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

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

เนื่องจากภาษาที่เราทำงานในไม่ได้มี DSL ดังกล่าวและจะยังคงดังนั้นบางครั้งเรายังคงต้องแสดงความคิดเห็น มันเป็นเรื่องของการศึกษาระดับปริญญา บางครั้งปัญหาคือการจับคู่ที่ดีกับภาษาในมือ แต่มักจะไม่

ดูสิ่งนี้ด้วย...

ฉันทำงานที่ไหนสักแห่งที่ไม่อนุญาตให้แสดงความคิดเห็นแบบอินไลน์ (เช่นคุณสามารถมีเพียงความคิดเห็นที่ด้านบนสุดของฟังก์ชั่น) ไม่มันไม่ทำให้อ่านรหัสง่ายขึ้น มันทำให้คำสั่งของขนาดแย่ลง

ฉันหลีกเลี่ยงการแสดงความคิดเห็นรหัสและใช้งานได้

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

และใช่ฉันรู้ว่า docblock นั้นเป็นความคิดเห็นทางเทคนิคแต่ทว่ามันเป็นส่วนเสริมของโค้ดไม่ใช่การล่วงล้ำและ "มาตรฐาน" ... ทุกสิ่งที่ความคิดเห็นทั่วไปไม่ใช่

สิ่งที่ฉันคิดว่าสามารถใช้แทนความคิดเห็นได้: ภาษา docblock / syntax / idiom ที่ได้มาตรฐานซึ่งเป็นคำอธิบายประกอบใน java

ไม่เพียง แต่จะไม่ส่งผลกระทบต่อคุณภาพ - อย่างที่คนอื่นสังเกตเห็น แต่มันจะน่ารำคาญจริงๆ

ฉันแน่ใจว่าพวกเราส่วนใหญ่ได้ทำสิ่งนี้เป็นครั้งคราว:

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

มันจะน่ารำคาญขนาดไหนถ้าคุณไม่สามารถคอมเม้นท์โค้ดสองสามบรรทัดเพื่อหาว่าบั๊กนั้นมาจากไหน?

โดยไม่คำนึงถึงความคิดเห็นเกี่ยวกับวิธีการทำงานของรหัสสิ่งที่ใช้งานง่ายเช่นนั้นหรือวางในTODOบันทึกย่อที่สะดวกคือสิ่งที่ทำให้การแก้ไขปัญหาเล็กน้อยง่ายขึ้นและจดจำสิ่งที่เรากำลังทำเมื่อเราเริ่มเขียนโค้ด

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

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

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

โปรแกรมเมอร์ที่ไม่มีระเบียบวินัยจะเขียนโค้ดไม่ดีไม่ว่าจะเป็นภาษาใดก็ตาม

ที่น่าสนใจว่าไพ ธ อนซึ่งเพิ่งมีการประชุมแบบส่วนตัว (_- คำนำหน้า) ไม่ได้พยายามตำรวจใด ๆ และยังมีการเขียนรหัสที่ละเอียดมาก

พูดจาโผงผาง: บางครั้งฉันคิดว่า langugages อนุญาตมากขึ้นจะบังคับให้ผู้คนมากขึ้นที่จะเรียนรู้รหัสอย่างถูกต้องมากกว่าย้อนกลับ (เช่นเดียวทางเดียวของ Java และสาปแช่งคุณถ้าคุณต้องการคิดว่าฟังก์ชั่นเป็นวัตถุชั้นหนึ่ง)

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

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

ตัวอย่างเช่นหากจำเป็นต้องมีส่วนของรหัสในการปฏิบัติตามกฎระเบียบเฉพาะคุณจะอธิบายได้อย่างไรโดยไม่ต้องแสดงความคิดเห็น หากอัลกอริทึมที่ใช้โดยรหัสส่วนใดส่วนหนึ่งมีการอธิบายไว้ในกระดาษที่เขียนในปี 1998 โดย M. Matsumoto และ T. Nishimura คุณจะอธิบายได้อย่างไรว่าไม่มีความคิดเห็น? หากอัลกอริทึมไม่ได้มีฟังก์ชั่นที่เหมาะสม แต่ทำการประนีประนอมอย่างเป็นธรรมโดยเฉพาะที่อาจทำให้เกิดปัญหาในอนาคตหากมีการเปลี่ยนแปลงรหัสอื่นคุณจะอธิบายได้อย่างไรโดยไม่มีความคิดเห็น

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

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

(if (= x y)
    x
    y)

... ลงในนี้:

(if (= x y)
    :then x
    :else y)

หากคุณต้องการคุณสามารถเชื่อมโยงความคิดเห็นคำเดียวหลายคำเพื่อสร้างความคิดเห็นแบบอินไลน์:

(if x :Remember, :x :could :be :nil!
    ...)

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

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

สาเหตุที่เป็นความคิดที่ดี: ไม่มี

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

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