รหัสเอกสาร: สาธารณะกับไม่ใช่สาธารณะ?


10

ฉันเป็นหนึ่งในนักพัฒนาที่มีความคิดว่าโค้ดที่เขียนควรอธิบายตนเองและอ่านเหมือนหนังสือ

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

เพียงมองหามาตรฐานและแนวทางปฏิบัติที่คุณเห็นหรือใช้ในการเดินทางของคุณ

คำตอบ:


12

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

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

ทั้งหมดนี้เป็นเรื่องที่ค่อนข้างคิดคุณ


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

3

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

ในส่วนหัวของชั้นเรียน:

  • ส่วนหัวรวม (ทำไม)
  • คำจำกัดความของคลาสเสมอ (วัตถุประสงค์และความรับผิดชอบ)
  • ฟังก์ชั่นเสมือนบริสุทธิ์เสมอ (สัญญาเต็ม)
  • ฟังก์ชั่นแบบอินไลน์เว้นแต่ getters อธิบายตนเอง
  • ประกาศประเภทอื่น ๆ เว้นแต่จะอธิบายตนเอง
  • สมาชิกข้อมูลแบบคงที่ (ทำไม)
  • สมาชิกข้อมูลอื่น ๆ ยกเว้นจะอธิบายตนเอง
  • มาโครหากมี (สัญญาและสาเหตุ)

ในรหัสการใช้งานระดับ:

  • ประกาศท้องถิ่นเช่นเดียวกับในส่วนหัว
  • นิยามฟังก์ชั่นเสมอ (สัญญาเต็ม)
  • นิยามฟังก์ชันสมาชิกเสมอ (สัญญาเต็มหรืออ้างอิงถึงรูทของการแทนที่เสมือน)
  • ตัวแปรสแตติกที่กำหนดถ้ามี (วัตถุประสงค์ทำไม)

ในส่วนหัวของเทมเพลต:

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


1

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


ตกลง แต่คุณไม่ได้ระบุความแตกต่างระหว่างเอกสารสำหรับ API สาธารณะและเอกสารสำหรับการทำงานภายใน
การแข่งขัน Lightness ใน Orbit

1

อย่างแน่นอน!

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.