เกิดอะไรขึ้นกับความคิดเห็นที่อธิบายรหัสที่ซับซ้อน?


236

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

คำถามของฉันมีดังต่อไปนี้:

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

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

ภาษาอังกฤษได้รับการออกแบบเพื่อให้มนุษย์เข้าใจได้ง่าย อย่างไรก็ตาม Java, Ruby หรือ Perl ได้รับการออกแบบมาเพื่อสร้างความสมดุลระหว่างความสามารถในการอ่านของมนุษย์และความสามารถในการอ่านคอมพิวเตอร์ดังนั้นจึงทำให้ความสามารถในการอ่านข้อความของมนุษย์ลดลง มนุษย์สามารถเข้าใจภาษาอังกฤษได้เร็วขึ้นมากว่าเขา / เธอสามารถเข้าใจรหัสด้วยความหมายเดียวกัน (ตราบใดที่การดำเนินการนั้นไม่สำคัญ)

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

บางคนจะพูดว่า "รหัสไม่ควรเข้าใจยาก", "ทำให้ฟังก์ชั่นเล็ก ๆ ", "ใช้ชื่อที่สื่อความหมาย", "อย่าเขียนรหัสสปาเก็ตตี้"

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

เป็นเรื่องที่ไม่ดีหรือไม่ที่จะอธิบายอัลกอริทึมที่ซับซ้อนพร้อมความคิดเห็นสองสามบรรทัดเกี่ยวกับการทำงานทั่วไป เกิดอะไรขึ้นกับการอธิบายรหัสที่ซับซ้อนพร้อมความคิดเห็น


14
หากเป็นเรื่องที่ซับซ้อนลอง refactoring มันเป็นชิ้นเล็ก ๆ
Vaughan Hilts

151
ในทางทฤษฎีไม่มีความแตกต่างระหว่างทฤษฎีและการปฏิบัติ ในทางปฏิบัติมี
Scott Leadley

5
@mattnz: เพิ่มเติมโดยตรงในเวลาที่คุณเขียนความคิดเห็นที่คุณแพร่หลายในปัญหารหัสนี้แก้ไข ครั้งต่อไปที่คุณเยี่ยมชมคุณจะมีความสามารถน้อยลงกับปัญหานี้
Steve Jessop

26
"อะไร" ฟังก์ชั่นหรือวิธีการทำควรจะชัดเจนจากชื่อของมัน มันเป็นวิธีที่ชัดเจนจากรหัสของมัน ทำไมมันถึงทำแบบนี้มีการใช้สมมติฐานโดยนัยใดซึ่งต้องใช้เอกสารเพื่ออ่านเพื่อทำความเข้าใจอัลกอริธึม ฯลฯ - ควรอยู่ในความคิดเห็น
SK-logic

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

คำตอบ:


408

ในแง่ของคนธรรมดา:

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

บรรทัดล่าง:

การอธิบายตัวเองเป็นสิ่งที่ดีไม่จำเป็นต้องทำเช่นนั้นดีกว่า


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

34
@ aecolley การเขียนโค้ดอธิบายตนเองเพื่อเริ่มต้นนั้นยังดีกว่า
Tulains Córdova

127
บางครั้งรหัสอธิบายตนเองไม่ได้มีประสิทธิภาพเพียงพอที่จะแก้ปัญหาด้วย HW&SW ในปัจจุบัน และตรรกะทางธุรกิจเป็นที่รู้จักกันดี ... คดเคี้ยว ชุดย่อยของปัญหาที่มีโซลูชันซอฟต์แวร์ที่สง่างามมีขนาดเล็กกว่าชุดของปัญหาที่มีประโยชน์ในเชิงเศรษฐกิจในการแก้ปัญหา
Scott Leadley

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

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

110

มีหลายเหตุผลที่ทำให้รหัสมีความซับซ้อนหรือสับสน ที่พบมากที่สุดด้วยเหตุผลที่ได้รับการแก้ไขที่ดีที่สุดโดย refactoring รหัสที่จะทำให้มันเกิดความสับสนน้อยไม่ได้โดยเพิ่มความคิดเห็นใด ๆ

อย่างไรก็ตามมีหลายกรณีที่ความคิดเห็นที่ถูกเลือกเป็นตัวเลือกที่ดีที่สุด

  • ถ้ามันเป็นอัลกอริธึมที่ซับซ้อนและสับสนไม่ใช่แค่การนำไปใช้ - ชนิดที่เขียนขึ้นในวารสารคณิตศาสตร์และหลังจากนั้นเรียกว่าอัลกอริทึมของ Mbogo - จากนั้นคุณใส่ความคิดเห็นที่จุดเริ่มต้นของการนำไปใช้ บางอย่างเช่น "นี่คืออัลกอริทึมของ Mbogo สำหรับวิดเจ็ต refrobnicating ตามที่อธิบายไว้ที่นี่: [URL ของกระดาษ] การใช้งานนี้ประกอบด้วยการปรับแต่งโดย Alice และ Carol [URL ของกระดาษอื่น]" อย่าพยายามเข้าไปดูรายละเอียดมากกว่านั้น หากมีคนต้องการรายละเอียดเพิ่มเติมพวกเขาอาจต้องอ่านบทความทั้งหมด

  • หากคุณมีบางสิ่งที่สามารถเขียนเป็นหนึ่งหรือสองบรรทัดในสัญกรณ์เฉพาะบางอย่างและขยายออกเป็นรหัสใหญ่ที่กำหนดให้วางเครื่องหมายบรรทัดพิเศษหนึ่งหรือสองบรรทัดในข้อคิดเห็นข้างบนฟังก์ชันเป็นวิธีที่ดีในการ บอกผู้อ่านว่าควรทำอย่างไร นี้เป็นข้อยกเว้นที่ "แต่ถ้าความคิดเห็นที่ได้รับไม่ตรงกับรหัส" โต้แย้งเพราะสัญกรณ์เฉพาะอาจเป็นมากง่ายต่อการค้นหาข้อบกพร่องในกว่ารหัส (เป็นวิธีอื่นถ้าคุณเขียนข้อกำหนดเป็นภาษาอังกฤษแทน) ตัวอย่างที่ดีคือที่นี่: https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.cpp#1057 ...

    /**
     * Scan a unicode-range token.  These match the regular expression
     *
     *     u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
     *
     * However, some such tokens are "invalid".  There are three valid forms:
     *
     *     u+[0-9a-f]{x}              1 <= x <= 6
     *     u+[0-9a-f]{x}\?{y}         1 <= x+y <= 6
     *     u+[0-9a-f]{x}-[0-9a-f]{y}  1 <= x <= 6, 1 <= y <= 6
    
  • หากรหัสตรงไปตรงมาโดยรวม แต่มีหนึ่งหรือสองสิ่งที่ดูซับซ้อนเกินไปไม่จำเป็นหรือผิดธรรมดา แต่ต้องเป็นอย่างนั้นเพราะเหตุผลคุณต้องใส่ความคิดเห็นเหนือบิตที่น่าสงสัยในทันที คุณระบุเหตุผล นี่เป็นตัวอย่างง่ายๆที่สิ่งเดียวที่ต้องอธิบายคือเหตุผลที่ค่าคงที่มีค่าที่แน่นอน

    /* s1*s2 <= SIZE_MAX if s1 < K and s2 < K, where K = sqrt(SIZE_MAX+1) */
    const size_t MUL_NO_OVERFLOW = ((size_t)1) << (sizeof(size_t) * 4);
    if ((nmemb >= MUL_NO_OVERFLOW || size >= MUL_NO_OVERFLOW) &&
        nmemb > 0 && SIZE_MAX / nmemb < size)
      abort();
    

25
นั่นคือความชั่วร้ายที่4ควรจะเป็นCHAR_BIT / 2;-)
Steve Jessop

@SteveJessop: มีอะไรขัดขวางการดำเนินการที่CHAR_BITS16 และ sizeof (size_t) เป็น 2 แต่ค่าสูงสุดของ size_t คือเช่น 2 ^ 20 [size_t ที่มีบิตแพ็ด 12 บิต]
supercat

2
@supercat ฉันไม่เห็นอะไรเลยที่เห็นได้ชัดว่าห้ามใน C99 ซึ่งหมายความว่าตัวอย่างนั้นไม่ถูกต้องทางเทคนิค มันเกิดขึ้นจาก (เวอร์ชันที่ปรับเปลี่ยนเล็กน้อย) ของ OpenBSD reallocarrayและโดยทั่วไป OpenBSD ไม่เชื่อในความเป็นไปได้ที่จะไม่เกิดขึ้นในABI ของพวกเขา
zwol

3
@ แซค: หากรหัสถูกออกแบบมาตามสมมติฐาน POSIX การใช้ CHAR_BITS อาจให้ความรู้สึกว่ารหัสสามารถทำงานกับค่าอื่นที่ไม่ใช่ 8
supercat

2
@Zack: intสำหรับประเภทที่ไม่ได้ลงชื่อแน่นอนความกว้างที่จะเป็นประโยชน์ในความหมายของพวกเขาจะต้องมีการกำหนดเป็นอิสระจากขนาดของ ในขณะที่มันจะให้uint32_t x,y,z;ความหมายของขึ้นอยู่กับขนาดของ(x-y) > z intนอกจากนี้ภาษาที่ออกแบบมาสำหรับการเขียนโค้ดที่มีประสิทธิภาพควรอนุญาตให้โปรแกรมเมอร์แยกความแตกต่างระหว่างประเภทที่การคำนวณคาดว่าจะเกินช่วงของประเภทและควรปิดเสียงเงียบเมื่อเทียบกับหนึ่งในกรณีที่การคำนวณเกินช่วงของประเภทที่ควรดัก ไม่คาดว่าจะเกินช่วงของประเภท แต่ ...
supercat

61

แล้วการอธิบายโค้ดที่ซับซ้อนกับความคิดเห็นมีอะไรผิดปกติ?

ไม่ใช่คำถามถูกหรือผิด แต่เป็น 'แนวปฏิบัติที่ดีที่สุด' ตามที่นิยามไว้ในบทความ Wikipedia :

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

ดังนั้นวิธีปฏิบัติที่ดีที่สุดคือพยายามปรับปรุงรหัสก่อนและใช้ภาษาอังกฤษหากไม่สามารถทำได้

ไม่ใช่กฎหมาย แต่เป็นเรื่องปกติมากที่จะพบรหัสความคิดเห็นที่ต้องมีการปรับโครงสร้างใหม่กว่ารหัสที่ได้รับการปรับสภาพใหม่ที่ต้องมีความคิดเห็นวิธีปฏิบัติที่ดีที่สุดสะท้อนให้เห็นถึงสิ่งนี้


42
+1 สำหรับ "เป็นเรื่องปกติมากในการค้นหารหัสความคิดเห็นที่ต้องการการปรับโครงสร้างใหม่กว่ารหัสที่ทำการปรับสภาพใหม่ที่ต้องการความคิดเห็น"
Brandon

7
โอเค แต่ความเห็นนั้นบ่อยแค่ไหน: //This code seriously needs a refactor
Erik Reppen

2
แน่นอนว่าแนวปฏิบัติที่ดีที่สุดที่ไม่ได้รับการสนับสนุนโดยการศึกษาทางวิทยาศาสตร์อย่างเข้มงวดนั้นเป็นเพียงความเห็น
Blrfl

54

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

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

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

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

ดังนั้นฉันไม่คิดว่าความคิดเห็นเป็นคำขอโทษสำหรับโค้ดที่ไม่ดี แต่อาจเป็นคำอธิบายว่าทำไมคุณถึงไม่ทำสิ่งที่ชัดเจน การมี// The standard approach doesn't work against the 64 bit version of the Frobosticate Libraryจะทำให้นักพัฒนาในอนาคตรวมถึงตัวคุณในอนาคตสนใจกับส่วนนั้นของรหัสและทดสอบกับไลบรารีนั้น แน่นอนว่าคุณอาจแสดงความคิดเห็นในการควบคุมแหล่งที่มาของคุณกระทำเช่นกัน แต่ผู้คนจะดูเฉพาะสิ่งที่ผิดพลาด พวกเขาจะอ่านความคิดเห็นของรหัสเมื่อพวกเขาเปลี่ยนรหัส

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

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


5
@ คริสเตียนมันคืออะไร? บรรทัดแรกอ้างถึงข้อความนั้นอย่างแน่นอน แต่นอกเหนือจากนั้นมันก็กว้างขึ้นเล็กน้อยเมื่อฉันเข้าใจ
ล็นทรอน

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

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

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

1
@Lilienthal ฉันไม่คิดว่าพาราสุดท้ายจะถูก จำกัด เฉพาะโครงการส่วนตัว - เขาพูดว่า "... ฉันยังคงแสดงความคิดเห็นในส่วนที่ฉันรู้สึกสับสน"
Wildcard

29

ความต้องการความคิดเห็นเป็นสัดส่วนผกผันกับระดับนามธรรมของรหัส

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

main:   
; initializes the two numbers and the counter.  Note that this assumes
; that the counter and num1 and num2 areas are contiguous!
;
    mov ax,'00'                     ; initialize to all ASCII zeroes
    mov di,counter                  ; including the counter
    mov cx,digits+cntDigits/2       ; two bytes at a time
    cld                             ; initialize from low to high memory
    rep stosw                       ; write the data
    inc ax                          ; make sure ASCII zero is in al
    mov [num1 + digits - 1],al      ; last digit is one
    mov [num2 + digits - 1],al      ; 
    mov [counter + cntDigits - 1],al

    jmp .bottom         ; done with initialization, so begin

.top
    ; add num1 to num2
    mov di,num1+digits-1
    mov si,num2+digits-1
    mov cx,digits       ; 
    call    AddNumbers  ; num2 += num1
    mov bp,num2         ;
    call    PrintLine   ;
    dec dword [term]    ; decrement loop counter
    jz  .done           ;

    ; add num2 to num1
    mov di,num2+digits-1
    mov si,num1+digits-1
    mov cx,digits       ;
    call    AddNumbers  ; num1 += num2
.bottom
    mov bp,num1         ;
    call    PrintLine   ;
    dec dword [term]    ; decrement loop counter
    jnz .top            ;
.done
    call    CRLF        ; finish off with CRLF
    mov ax,4c00h        ; terminate
    int 21h             ;

แม้ว่าจะมีความคิดเห็นก็ตามมันอาจซับซ้อนมาก

ตัวอย่างที่ทันสมัย: Regexes มักจะมีโครงสร้างนามธรรมที่ต่ำมาก (ตัวอักษรตัวพิมพ์เล็กหมายเลข 0, 1, 2, บรรทัดใหม่ ฯลฯ ) พวกเขาอาจต้องการความคิดเห็นในรูปแบบตัวอย่าง (Bob Martin, IIRC รับทราบสิ่งนี้) นี่คือ regex ที่ (ฉันคิดว่า) ควรตรงกับ HTTP (S) และ FTP URL:

^(((ht|f)tp(s?))\://)?(www.|[a-zA-Z].)[a-zA-Z0-9\-\.]+\.(com|edu|gov|m
+il|net|org|biz|info|name|museum|us|ca|uk)(\:[0-9]+)*(/($|[a-zA-Z0-9\.
+\,\;\?\'\\\+&amp;%\$#\=~_\-]+))*$

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

ผมคิดว่าสูตรตัวเลขใน Cส่วนใหญ่แปลคำต่อคำเพื่อสูตรตัวเลขใน C ++ซึ่งผมอนุมานเริ่มเป็นสูตรตัวเลข (ใน FORTAN) กับตัวแปรทั้งหมดa, aa, b, c, ccฯลฯ คงผ่านแต่ละรุ่น อัลกอริทึมอาจถูกต้อง แต่พวกเขาไม่ได้ใช้ประโยชน์จาก abstractions ภาษาที่ให้ไว้ และพวกเขาปิดฉันลง ตัวอย่างจากบทความของดร. ดอบส์ - การแปลงฟูริเยร์อย่างรวดเร็ว :

void four1(double* data, unsigned long nn)
{
    unsigned long n, mmax, m, j, istep, i;
    double wtemp, wr, wpr, wpi, wi, theta;
    double tempr, tempi;

    // reverse-binary reindexing
    n = nn<<1;
    j=1;
    for (i=1; i<n; i+=2) {
        if (j>i) {
            swap(data[j-1], data[i-1]);
            swap(data[j], data[i]);
        }
        m = nn;
        while (m>=2 && j>m) {
            j -= m;
            m >>= 1;
        }
        j += m;
    };

    // here begins the Danielson-Lanczos section
    mmax=2;
    while (n>mmax) {
        istep = mmax<<1;
        theta = -(2*M_PI/mmax);
        wtemp = sin(0.5*theta);
        wpr = -2.0*wtemp*wtemp;
        wpi = sin(theta);
        wr = 1.0;
        wi = 0.0;
        for (m=1; m < mmax; m += 2) {
            for (i=m; i <= n; i += istep) {
                j=i+mmax;
                tempr = wr*data[j-1] - wi*data[j];
                tempi = wr * data[j] + wi*data[j-1];

                data[j-1] = data[i-1] - tempr;
                data[j] = data[i] - tempi;
                data[i-1] += tempr;
                data[i] += tempi;
            }
            wtemp=wr;
            wr += wr*wpr - wi*wpi;
            wi += wi*wpr + wtemp*wpi;
        }
        mmax=istep;
    }
}

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

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


1
dec dword [term] ; decrement loop counterไม่มีใครควรจะเขียนบรรทัดเช่นนี้ในภาษาการชุมนุม: ในทางกลับกันตัวอย่างภาษาแอสเซมบลีที่หายไปของคุณคือความคิดเห็นก่อน "ย่อหน้าย่อหน้า" แต่ละคำอธิบายสิ่งที่บล็อกโค้ดถัดไปทำ ในกรณีนั้นความคิดเห็นโดยทั่วไปจะเทียบเท่ากับบรรทัดเดียวใน pseudocode เช่น;clear the screenตามด้วย 7 บรรทัดที่ใช้เพื่อล้างหน้าจอ
Scott Whitlock

1
ใช่มีสิ่งที่ฉันจะพิจารณาความเห็นที่ไม่จำเป็นในตัวอย่างการชุมนุม แต่เพื่อความยุติธรรมมันเป็นตัวแทนของรูปแบบการชุมนุม 'ดี' สวย แม้จะมีคำนำหน้าย่อหน้าหนึ่งหรือสองบรรทัดโค้ดก็ยากที่จะติดตาม ฉันเข้าใจตัวอย่าง ASM ดีกว่าตัวอย่าง FFT ฉันตั้งโปรแกรม FFT ใน C ++ ในโรงเรียนระดับประถมศึกษาและมันก็ไม่ได้มีลักษณะเช่นนี้ แต่จากนั้นเราก็ใช้ STL ตัววนซ้ำฟังก์ชั่นการโทรด้วยวิธีการค่อนข้างน้อย ไม่เร็วเท่ากับฟังก์ชั่นเสาหิน แต่อ่านง่ายขึ้นมาก ฉันจะลองเพิ่มมันเพื่อตัดกับตัวอย่าง NRinC ++
Kristian H

คุณหมายถึง^(((ht|f)tps?)\:\/\/)?(www\.)*[a-zA-Z0-9\-\.]+\.(com|edu|gov|mil|net|org|biz|info|name|museum|us|ca|uk)(\:[0-9]+)*(\/($|[a-zA-Z0-9\.\,\;\?\'\\\+&%\$#\=~_\-]+))*$อะไร ระวังที่อยู่ตัวเลข
izabera

จุดของฉันมากขึ้นหรือน้อยลง: บางสิ่งที่สร้างขึ้นจาก abstractions ระดับต่ำมากไม่ใช่เรื่องง่ายที่จะอ่านหรือตรวจสอบ ความคิดเห็น (และเพื่อไม่ให้อยู่ห่างไกลเกินกว่าการทดสอบ TESTS) อาจมีประโยชน์และไม่ใช่ความเสียหาย ในขณะเดียวกันการไม่ใช้ abstractions ระดับที่สูงกว่าที่มีอยู่ (: alpha:: NUM: ถ้ามี) ทำให้ยากต่อการเข้าใจแม้จะมีความคิดเห็นที่ดีกว่าการใช้ abstractions ระดับที่สูงขึ้น
Kristian H

3
+1: "The need for comments is inversely proportional to the abstraction level of the code." ผลรวมทุกอย่างที่นั่นสวยมาก
Gerrat

21

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

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

อย่างไรก็ตามการใช้ความคิดเห็นดังกล่าวข้างต้นไม่เป็นโมฆะ เราไม่ได้อยู่ในโลกที่เหมาะดังนั้นเมื่อใด ๆ ข้างต้นล้มเหลวด้วยเหตุผลใดก็ตามฉันอยากจะมีบางความเห็นที่จะถอยกลับ


18

ฉันคิดว่าคุณอ่านมากเกินไปในสิ่งที่เขาพูด การร้องเรียนของคุณมีสองส่วน:

เกิดอะไรขึ้นกับการอธิบาย (1) อัลกอริธึมที่ซับซ้อนหรือ (2) โค้ดที่ยาวและซับซ้อนซึ่งมีความคิดเห็นเชิงอธิบาย

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

อย่างไรก็ตามรหัสส่วนใหญ่ไม่ได้เป็น (1) คุณจะเขียนซอฟต์แวร์ที่ไม่มีอะไรเลยนอกจากการใช้งาน mutex แบบรีดด้วยมือการปิดกั้นการดำเนินงานพีชคณิตเชิงเส้นด้วยการสนับสนุนห้องสมุดที่ไม่ดีและอัลกอริธึมใหม่ที่รู้จักเฉพาะกลุ่มวิจัยของ บริษัท คุณเท่านั้น รหัสส่วนใหญ่ประกอบด้วยการเรียกไลบรารี่ / กรอบ / API, IO, boilerplate และการทดสอบหน่วย

นี่คือรหัสที่มาร์ตินพูดถึง และเขาตอบคำถามของคุณด้วยคำพูดจาก Kernighan และ Plaugher ที่ด้านบนของบท:

อย่าแสดงความคิดเห็นรหัสที่ไม่ดี - เขียนใหม่

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

และนี่คือสิ่งที่มาร์ตินพูดว่า:

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

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

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


3
หากนักพัฒนาซอฟต์แวร์ที่ฉันทำงานด้วยก็แค่เขียนว่า "แฮ็คระดับบิตที่ลอยระดับความชั่วร้าย" เพื่ออธิบายอัลกอริทึมรากที่รวดเร็ว - พวกเขาต้องการพูดคุยกับฉัน ตราบใดที่พวกเขารวมการอ้างอิงไปยังที่ที่มีประโยชน์มากกว่าฉันก็มีความสุข
Michael Anderson

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

2
@trysis haha, ใช่ แต่ในโลกที่โปรแกรมเมอร์มีความรับผิดชอบและไม่ใช่นักธุรกิจพวกเขาจะไม่ส่งสินค้าเพราะพวกเขาจะต้องใช้ทองคำเป็นประจำตลอดกาลในการแสวงหาความสมบูรณ์แบบ
gbjbaanb

4
@PatrickCollins เกือบทุกอย่างที่ฉันอ่านบนเว็บเกี่ยวกับการทำมันถูกต้องในครั้งแรก แทบไม่มีใครอยากเขียนบทความเกี่ยวกับการแก้ไขเรื่องยุ่งเหยิง! นักฟิสิกส์บอกว่า "ได้รับทรงกลมที่สมบูรณ์แบบ ... " นักวิทยาศาสตร์กล่าวว่า "ได้รับการพัฒนาที่เขียวขจี ... "
gbjbaanb

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

8

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

ไม่มีอะไรเช่นนี้ เอกสารการทำงานของคุณเป็นแนวปฏิบัติที่ดี

ที่กล่าวว่าคุณมีขั้วคู่ผิดที่นี่: การเขียนโค้ดที่สะอาดและการเขียนโค้ดที่เป็นเอกสาร - ทั้งสองไม่ได้อยู่ในการต่อต้าน

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

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

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

จริง นี่คือเหตุผลที่อัลกอริธึม API สาธารณะของคุณควรอธิบายไว้ในเอกสารประกอบ

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

โดยหลักการแล้วหลังจากเขียนโค้ดที่ซับซ้อนแล้วคุณควร (ไม่ใช่รายการที่ครบถ้วน):

  • พิจารณาร่าง (เช่นวางแผนที่จะเขียนใหม่)
  • ทำจุดเข้าใช้งานอัลกอริธึมให้เป็นระเบียบ / อินเทอร์เฟซ / บทบาท / ฯลฯ (วิเคราะห์และปรับอินเทอร์เฟซให้เป็นรูปแบบเป็นนามธรรมสรุปเงื่อนไขของเอกสาร
  • เขียนแบบทดสอบ
  • ทำความสะอาดและ refactor

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

[... ] อัลกอริทึมบางอย่างมีความซับซ้อน และดังนั้นจึงยากที่จะเข้าใจเมื่ออ่านพวกเขาทีละบรรทัด

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

เป็นเรื่องที่ไม่ดีหรือไม่ที่จะอธิบายอัลกอริทึมที่ซับซ้อนพร้อมความคิดเห็นสองสามบรรทัดเกี่ยวกับการทำงานทั่วไป

ไม่ - นั่นเป็นสิ่งที่ดี การเพิ่มความคิดเห็นไม่กี่บรรทัดนั้นไม่เพียงพอ

เกิดอะไรขึ้นกับการอธิบายรหัสที่ซับซ้อนพร้อมความคิดเห็น

ความจริงที่ว่าคุณไม่ควรมีรหัสที่ซับซ้อนหากสามารถหลีกเลี่ยงได้

เพื่อหลีกเลี่ยงรหัสที่ซับซ้อนให้อินเทอร์เฟซของคุณเป็นทางการใช้เวลามากกว่า ~ 8 เท่าในการออกแบบ API มากกว่าที่คุณใช้ในการดำเนินการ (Stepanov แนะนำให้ใช้เวลาอย่างน้อย 10 เท่าบนอินเทอร์เฟซ คุณกำลังสร้างโครงการไม่ใช่เพียงแค่เขียนอัลกอริทึม

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


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

6

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

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

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

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

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


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

1
@ naught101: ใช่โดยเฉพาะอย่างยิ่งเนื่องจากกระดาษที่คุณอ้างถึงอาจใช้ชื่อตัวแปรตัวอักษรเดียว โดยปกติแล้วจะง่ายกว่าที่จะเห็นว่ารหัสนั้นปฏิบัติตามบทความหากคุณใช้ชื่อเดียวกัน แต่มันขัดแย้งกับเป้าหมายของรหัสที่อธิบายตัวเองได้ (อธิบายโดยกระดาษแทน) ในกรณีนี้ความคิดเห็นที่แต่ละชื่อมีการกำหนดความหมายว่ามันหมายถึงอะไรจริงทดแทนสำหรับชื่อที่มีความหมาย
Steve Jessop

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

1
@ FlorianF: การตอบสนองแบบดั้งเดิมคือชื่อตัวแปรและฟังก์ชั่นควรระบุคร่าวๆว่าโค้ดนั้นเกี่ยวกับอะไรและให้คุณอ่านสิ่งที่ไม่ได้กำลังมองหาอยู่อย่างแน่นอน ฉันเห็นด้วยกับคุณว่าสิ่งนี้จะไม่ประสบความสำเร็จเสมอไป แต่ฉันไม่เห็นด้วยอย่างยิ่งที่ฉันคิดว่ารหัสทั้งหมดต้องได้รับการแสดงความคิดเห็นเพื่อช่วยในการค้นหาหรืออ่านสกิม แต่คุณถูกต้องนั่นเป็นกรณีที่มีคนอ่านโค้ดของคุณและไม่ต้องเข้าใจมัน
Steve Jessop

2
@Snowman ผู้คนสามารถทำได้ด้วยชื่อตัวแปร ฉันเห็นโค้ดที่รายการ listOfApples มีรายการ Bananas มีคนคัดลอกรหัสการประมวลผลรายการของแอปเปิ้ลและปรับใช้สำหรับกล้วยโดยไม่ต้องเปลี่ยนชื่อตัวแปร
Florian F

5

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

// This code implements the algorithm described in requirements document 239.

หรือเพียงแค่

void doPRD239Algorithm() { ...

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

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

มีอีกประเภทหนึ่งของรหัสที่ไม่ได้เป็นอัลกอริทึมมากเป็นระบบราชการ คุณต้องตั้งค่าพารามิเตอร์สำหรับระบบอื่นหรือทำงานร่วมกับข้อบกพร่องของคนอื่น:

/* Configure the beam controller and turn on the laser.
The sequence is timing-critical and this code must run with interrupts disabled.
Note that the constant 0xef45ab87 differs from the vendor documentation; the vendor
is wrong in this case.
Some of these operations write the same value multiple times. Do not attempt
to optimise this code by removing seemingly redundant operations.
*/

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

5

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

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

ตัวอย่างเช่น:

// The getter.
public <V> V get(final K key, Class<V> type) {
  // Has it run yet?
  Future<Object> f = multitons.get(key);
  if (f == null) {
    // No! Make the task that runs it.
    FutureTask<Object> ft = new FutureTask<Object>(
            new Callable() {

              public Object call() throws Exception {
                // Only do the create when called to do so.
                return key.create();
              }

            });
    // Only put if not there.
    f = multitons.putIfAbsent(key, ft);
    if (f == null) {
      // We replaced null so we successfully put. We were first!
      f = ft;
      // Initiate the task.
      ft.run();
    }
  }
  try {
    /**
     * If code gets here and hangs due to f.status = 0 (FutureTask.NEW)
     * then you are trying to get from your Multiton in your creator.
     *
     * Cannot check for that without unnecessarily complex code.
     *
     * Perhaps could use get with timeout.
     */
    // Cast here to force the right type.
    return (V) f.get();
  } catch (Exception ex) {
    // Hide exceptions without discarding them.
    throw Throwables.asRuntimeException(ex);
  }
}

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

PS: ฉันพบแหล่งที่มาที่ฉันอ้างถึง - การเข้ารหัสสยองขวัญ: รหัสบอกคุณได้อย่างไรความคิดเห็นบอกคุณว่าทำไม


8
ความคิดเห็นแรก: มันทำงานหรือยัง ทำงานอะไรบ้าง เหมือนกันสำหรับความคิดเห็นอื่น ๆ สำหรับบางคนที่ไม่รู้ว่าโค้ดทำอะไร
gnasher729

1
@ gnasher729 - นำออกไปจากบริบทความคิดเห็นใด ๆ เกือบจะไร้ประโยชน์ - รหัสนี้คือการสาธิตของการเพิ่มความคิดเห็นที่บ่งบอกถึงความตั้งใจมากกว่าความพยายามที่จะอธิบาย ฉันขอโทษที่ไม่ได้ทำอะไรเพื่อคุณ
OldCurmudgeon

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

BTW - The มีมันทำงานยังแสดงความคิดเห็นคือหมายถึงFutureและแสดงให้เห็นว่าget()ตามด้วยการตรวจสอบกับnullตรวจพบว่าFutureมีการเรียกใช้แล้ว - ถูกต้องเอกสารเจตนามากกว่ากระบวนการ
OldCurmudgeon

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

4

แต่เราทุกคนรู้ว่าไม่เพียงพอ

จริงๆ? ตั้งแต่เมื่อไหร่

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

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


7
ฉันรู้ว่ามันไม่เพียงพอ
Florian F

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

3
ฉันเคยพยายามถอดรหัสรหัสของผู้อื่นที่ฉันต้องการได้เพิ่มความคิดเห็นมากกว่าหนึ่งครั้งทุกสองปี
Ogre Psalm33

@ OgrePsalm33 - พวกเขามีวิธีการขนาดเล็กและใช้ชื่อที่ดีหรือไม่? รหัสไม่ดีไม่ดีโดยไม่คำนึงถึงความคิดเห็น
Telastyn

2
@Telastyn แต่น่าเสียดายที่เมื่อทำงานกับฐานรหัสขนาดใหญ่วิธีการ "เล็ก" และชื่อ "ดี" นั้นขึ้นอยู่กับผู้พัฒนาแต่ละคน (ดังนั้นจึงเป็นความคิดเห็นที่ดีสำหรับเรื่องนั้น) นักพัฒนาที่เขียนโค้ดอัลกอริทึมการประมวลผลกราฟิก Flarbigan เป็นเวลา 7 ปีสามารถเขียนสิ่งที่ชัดเจนอย่างสมบูรณ์สำหรับเขาและนักพัฒนาที่คล้ายกัน จากนั้น 2 สัปดาห์ต่อมาผู้เชี่ยวชาญ Flarbigan หยุดทำงาน
Ogre Psalm33

2

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

ความคิดเห็นในแหล่งข้อมูลเป็นรูปแบบหนึ่งของเอกสารประกอบสำหรับโปรแกรมเมอร์อื่น ๆ (รวมถึงตัวคุณเอง) หากความคิดเห็นเกี่ยวกับปัญหาเชิงนามธรรมมากกว่าโค้ดที่ทำในทุกขั้นตอนแสดงว่าคุณทำได้ดีกว่าค่าเฉลี่ย ระดับของนามธรรมนั้นแตกต่างกันไปตามเครื่องมือที่คุณใช้ ความคิดเห็นประกอบกับรูทีนภาษาแอสเซมบลีมักจะมีระดับ "abstraction" ต่ำกว่าตัวอย่างเช่น APL A←0⋄A⊣{2⊤⍵:1+3×⍵⋄⍵÷2}⍣{⍺=A+←1}⎕นี้ ฉันคิดว่าน่าจะได้รับความคิดเห็นเกี่ยวกับปัญหาที่ตั้งใจจะแก้ไขใช่มั้ย?


2

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

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

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

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

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


สิ่งที่ฉันคิดเมื่อฉันไม่เห็นด้วยกับข้อความ "มนุษย์สามารถเข้าใจชิ้นส่วนของภาษาอังกฤษได้เร็วกว่ามากที่เขา / เธอสามารถเข้าใจชิ้นส่วนของรหัสที่มีความหมายเดียวกัน (ตราบเท่าที่การดำเนินการไม่สำคัญ)" มักจะคลุมเครือและรัดกุมน้อยกว่าเสมอ
stephenbayer

0

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

f1 = (float)(f2+f3); // Force result to be rounded to single precision
f4 = f1-f2;

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

thing.someFloatProperty = (float)(f2*0.1); // Divide by ten

ที่นี่วัตถุประสงค์ของนักแสดงคือเพื่อป้องกันคอมไพเลอร์จากการบีบเสียงด้วยวิธีที่มีประสิทธิภาพที่สุดในการคำนวณอย่างแม่นยำ (f2 / 10) [แม่นยำมากกว่าการคูณด้วย 0.1f และบนเครื่องส่วนใหญ่จะเร็วกว่าการหารด้วย 10.0f]

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


ฉันไม่แน่ใจว่า J. Random Programmer ซึ่งกำลังดูตัวอย่างที่สองจะรู้ว่าค่าคงที่ถูกเขียน 0.1 ด้วยเหตุผลที่ดีมากกว่าเพราะโปรแกรมเมอร์ดั้งเดิมลืมพิมพ์ 'f'
David K

โดยเฉพาะอย่างยิ่งในระหว่างการดีบั๊กคุณไม่เคยคิดว่าสิ่งใดที่ทำไปแล้วด้วยเหตุผลที่ดี
gnasher729

@DavidK: จุดประสงค์ของรหัสตัวอย่างที่สองของฉันคือการเปรียบเทียบกับรหัสชิ้นแรก ในโค้ดที่สองความตั้งใจของโปรแกรมเมอร์น่าจะsomeFloatPropertyเป็นตัวแทนที่แม่นยำที่สุดเท่าf2/10ที่จะทำได้ จุดประสงค์หลักของการโยนที่สองจึงเป็นเพียงเพื่อให้รวบรวมรหัส ในตัวอย่างแรก แต่หล่ออย่างชัดเจนไม่จำเป็นสำหรับวัตถุประสงค์ปกติ (เปลี่ยนชนิดหนึ่งเวลารวบรวมไปยังอีก) floatตั้งแต่ตัวถูกดำเนินการเป็นที่เรียบร้อยแล้ว ความคิดเห็นที่ทำหน้าที่ในการให้ชัดเจนว่านักแสดงเป็นสิ่งที่จำเป็นสำหรับจุดประสงค์รอง (ปัดเศษ)
supercat

ฉันเห็นด้วยกับความคิดที่ว่าคุณไม่จำเป็นต้องแสดงความคิดเห็นใด ๆ เกี่ยวกับ(float)นักแสดงในตัวอย่างที่สอง 0.1คำถามที่เป็นเรื่องเกี่ยวกับค่าคงที่แท้จริง คุณอธิบาย (ในย่อหน้าถัดไปของข้อความ) ทำไมเราถึงเขียน0.1: "มันแม่นยำกว่าคูณด้วย 0.1f" ฉันบอกว่าคนเหล่านั้นเป็นคำที่ควรจะอยู่ในการแสดงความคิดเห็น
David K

@DavidK: แน่นอนผมจะรวมถึงการแสดงความคิดเห็นถ้าผมรู้ว่า 0.1f จะคลุมเครือไม่น่าและจะใช้ 0.1f ถ้าฉันรู้ว่าการสูญเสียความแม่นยำจะเป็นที่ยอมรับและ0.1f ในความเป็นจริงจะเป็นสาระสำคัญได้เร็วขึ้นกว่า 0.1 หากฉันไม่ทราบว่าสิ่งเหล่านี้เป็นจริงอย่างใดอย่างหนึ่งที่ต้องการนิสัยการเขียนโปรแกรมของฉันที่ต้องการจะใช้doubleสำหรับค่าคงที่หรือการคำนวณระดับกลางซึ่งค่าอาจไม่สามารถแทนได้เช่นfloat[แม้ว่าในภาษาที่ต้องปลดเปลื้อง อาจใช้การใช้floatค่าคงที่ไม่ใช่ความเร็ว แต่เพื่อลดความน่ารำคาญ]
supercat

-1

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

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