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

182

หนึ่งในสมาชิกในทีมของฉันหลีกเลี่ยงการแสดงความคิดเห็นในรหัสของเขาอย่างสม่ำเสมอ

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

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

ฉันสามารถนำเสนอข้อโต้แย้งอะไรกับเขาเพื่อโน้มน้าวให้เขาจัดทำรหัสของเขาอย่างเหมาะสม?

ในบันทึกนั้นฉันผิดที่จะมุ่งเน้นไปที่ความคิดเห็นของรหัสหรือสิ่งนี้บ่งบอกถึงปัญหาที่ใหญ่กว่าซึ่งควรได้รับการแก้ไขหรือไม่?

teamwork team comments

— Mahbubur R Aaman
แหล่งที่มา

109

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

— Martin York

63

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

— Kaz

12

@Kaz Sarcasm (ฉันหวังว่า) แปลข้อความได้ไม่ดี

— deworde

10

@deworde & artjom - ใช่นั่นคือการเสียดสี ไม่มันไม่ได้สะอาดอย่างที่ควรจะเป็น แต่มันเป็นการพูดประชดประชันอย่างชัดเจน

17

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

— Anirudha

430

ความคิดเห็นเพียงอย่างเดียวไม่ได้ทำเพื่อรหัสที่ดีกว่าและเพียงแค่กด "ความคิดเห็นเพิ่มเติม" มีแนวโน้มที่จะให้คุณมากกว่า/* increment i by 1 */ความคิดเห็นสไตล์

ดังนั้นถามตัวเองว่าทำไมคุณถึงต้องการความคิดเห็นเหล่านั้น "เป็นวิธีปฏิบัติที่ดีที่สุด" ไม่นับเป็นอาร์กิวเมนต์ถ้าคุณไม่เข้าใจว่าทำไม

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

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

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

ในด้านทักษะของผู้คนหลีกเลี่ยงการทำให้เกิดเสียงหรือกล่าวโทษในทุกกรณี จริงจังกับคำถามของคุณอย่างจริงจัง

— tdammers
แหล่งที่มา

269

+1 สำหรับ "อย่าบ่นเกี่ยวกับความคิดเห็นที่ขาดหายไป: บ่นเกี่ยวกับรหัสที่อ่านไม่ได้"

— Md Mahbubur Rahman

4

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

— ซาอูล

40

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

— deworde

18

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

— Rob P.

5

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

— deworde

114

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

สิ่งที่ไม่เคยได้ผลคือ "บอกให้เพิ่มความคิดเห็นเพิ่มเติม" สิ่งนี้จะไม่เพิ่มความมีวินัยในตนเองหรือประสบการณ์ IMHO สิ่งเดียวที่อาจใช้ได้คือการทบทวนรหัส & การปรับโครงสร้างบ่อยครั้ง เมื่อนักพัฒนาซอฟต์แวร์ทำงานเสร็จแล้วให้เขา / เธออธิบายส่วนใด ๆ ของรหัสที่คุณไม่เข้าใจ refactor ทันทีหรือเอกสารรหัสในลักษณะที่คุณทั้งสองจะเข้าใจ 6 เดือนต่อมา

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

— Doc Brown
แหล่งที่มา

5

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

— Jimmy Hoffa

1

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

— Martin Brown

27

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

— Earlz
แหล่งที่มา

2

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

— Dunk

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

— Chris Lee

@ChrisLee ที่นโยบายการตรวจสอบรหัส บริษัท ของฉันไม่ได้บังคับใช้ทางเทคนิค แต่มีนโยบายที่ก่อนที่เรื่องราวจะถูกทำเครื่องหมายว่าพร้อมสำหรับการทดสอบจะต้องได้รับการตรวจสอบโค้ดไม่ว่าใครจะทำงานพัฒนา มันค่อนข้างน่าสนใจที่จะต้องมีการตรวจสอบโค้ดเมื่อ CTO ทำการเช็คอินแม้ว่า lol

— Earlz

18

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

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

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

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

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

— ตรงไปตรงมา
แหล่งที่มา

+1 สำหรับการอภิปรายผลกำไรที่เกิดขึ้นจริงจากความคิดเห็น ความคิดเห็นหมายถึงการเพิ่มมูลค่าให้กับซอร์สโค้ด

— ปาร์

1

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

— Dunk

3

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

— bharal

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

— Danubian Sailor

2

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

— GordonM

10

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

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

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

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

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

— kojiro
แหล่งที่มา

3

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

— GordonM

@GordonM คุณคิดว่าจะเป็นการดีกว่าที่จะไม่บอกพนักงานว่าพฤติกรรมของเขาไม่เหมาะสมและผลที่ตามมาของพฤติกรรมที่ไม่เหมาะสมอย่างต่อเนื่องจะเป็นอย่างไร

— kojiro

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

— GordonM

@GordonM ฉันใช้ข้อยกเว้นจริง ๆ ว่าสิ่งที่ฉันพูดนั้นเป็นสิ่งที่คุกคาม แต่อย่างไรก็ตามฉันได้แก้ไขมันแล้ว

— kojiro

8

รับซอฟต์แวร์ตรวจสอบรหัสและใช้งานได้ดี

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

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

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

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

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

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

— Danny Tuppeny
แหล่งที่มา

4

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

ทำไมต้องแสดงความคิดเห็น?

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

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

ความสามารถในการอ่านโค้ด! = ความคิดเห็นของโค้ด

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

ในทางกลับกันโปรแกรม readable = รหัส + เอกสารสามารถมีหลายส่วนที่ถูกต้องตามกฎหมายของความคิดเห็นเช่นเพื่ออำนวยความสะดวกในการสร้างเอกสาร "ความเห็นต่อ API"

ปฏิบัติตามมาตรฐานสไตล์โค้ด

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

กลายเป็นผู้สอนศาสนาที่สามารถอ่านรหัสได้

หากคุณยอมรับว่าโค้ดอ่านบ่อยกว่าที่เขียนไว้ หากการแสดงออกอย่างชัดเจนของความคิดและการคิดอย่างชัดเจนเป็นสิ่งสำคัญสำหรับคุณไม่ว่าจะใช้ภาษาใดในการสื่อสาร (คณิตศาสตร์รหัสเครื่องจักรหรือภาษาอังกฤษโบราณ) .. หากภารกิจของคุณคือการกำจัดความคิดทางเลือกที่น่าเบื่อและน่าเกลียด .. คนสุดท้ายมาจาก "รายการ" อื่น) .. ถามคำถามเริ่มต้นการอภิปรายเริ่มกระจายความคิดกระตุ้นหนังสือเกี่ยวกับการทำความสะอาดโค้ด (อาจไม่เพียง แต่สิ่งที่คล้ายกับรูปแบบการออกแบบของเบ็ค แต่คล้ายกับที่กล่าวมาแล้วโดย RC Martin ) ในการเขียนโปรแกรม ต่อไปเป็นหัวข้อย่อยของแนวคิดหลัก (อ้างอิงจากหนังสือของ O'Reilly เรื่องการอ่าน)

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

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

— Yauhen Yakimovich
แหล่งที่มา

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

— Nux

1

วิศวกรที่ดีใส่ใจเกี่ยวกับระบบทั้งหมด (รวมเอกสารที่ไม่ใช่ codegenerated.) - แต่ที่นี่เราแน่นอนใจเข้ารหัสทั่วไป .. จุดของฉันคือการที่ไม่ได้มีตัวบ่งชี้ในรหัสเรียกว่าfoo , บาร์ , tmpSomething2และIamJustTooSmartAssToCareแล้วปรับปรุง สถานการณ์และลดความต้องการโดยรวมในการอธิบายว่ารหัสคืออะไรและทำอะไร ควรเขียนโค้ดด้วย "โหมดการคิดบน" เช่น API ที่ออกแบบมาอย่างดีที่มนุษย์สามารถอ่านทำความเข้าใจนำมาใช้ใหม่และดูแลรักษาได้ มีความคิดเห็นมากเกินไปในรหัสที่เข้าใจยากเป็นสัญญาณที่แย่มาก!

— Yauhen Yakimovich

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

— Yauhen Yakimovich

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

— Nux

"ถ้าคุณทำให้การอ่านเป็นเรื่องสำคัญคุณจะไม่ต้องการความคิดเห็น" - ใช่นี่คือสิ่งที่ฉันพูด (และฉันรู้ว่านี่ไม่ใช่เรื่องง่ายที่จะบรรลุ) BTW คุณมีสถานการณ์เมื่อทำการรักษาประวัติการคอมมิชชัน (การควบคุมเวอร์ชัน) ไม่เพียงพอที่จะสะท้อนถึง "ข้อบกพร่อง / ความต้องการ / หมายเลขเรื่อง" หรือไม่? ฉันฝึกฝนมานานแล้ว - ทำงานให้ฉันและช่วยให้โค้ดไม่ว่างจากประวัติการพัฒนา .. ทำให้มันเติบโตน้อยลง

— เหยาเหมินยากิโมวิช

3

ฉันผิดที่จะมุ่งเน้นไปที่ความคิดเห็นของรหัสหรือสิ่งนี้บ่งบอกถึงปัญหาใหญ่ที่ควรได้รับการแก้ไขหรือไม่?

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

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

— พีท
แหล่งที่มา

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

— มาลาคี

3

ก่อนอื่นผมขอแนะนำให้คุณพูดถึงความคิดเห็นของคุณอีกครั้ง

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

ในกรณีส่วนใหญ่ที่ฉันพบพวกเขาความคิดเห็นที่ชั่วร้าย ฉันอยากจะแนะนำให้อ่านบทแสดงความคิดเห็นรหัสของ"Clean code" โดย Robert Martinเพื่อทำความเข้าใจว่าทำไม

ความคิดเห็นทำร้ายรหัสของคุณในหลายวิธี:

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

2) พวกเขามักจะโกหก คุณไม่สามารถเชื่อถือความคิดเห็นและต้องอ่านรหัสแทน สิ่งใดที่ทำให้เกิดคำถาม: ทำไมคุณถึงต้องการความคิดเห็นทั้งหมด?

// this method returns the sum of 'a' and 'b'
public int GetHash(int a, int b)
{
    //the calculation of the hash
    int result = a*b;
}

(แฮชไม่ใช่ผลรวม แต่เป็นผลิตภัณฑ์)

3) ความคิดเห็นยุ่งเหยิงรหัสและไม่ค่อยเพิ่มค่าใด ๆ

โซลูชันของฉัน: แทนที่จะเพิ่มความคิดเห็นให้มากขึ้นพยายามกำจัดพวกเขาทั้งหมด!

— Paul
แหล่งที่มา

4

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

— jmk

1

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

— DBlackborough

3

สิ่งสำคัญที่ต้องจำก็คือในขณะที่ทุกอย่างเข้าท่าคุณตอนนี้คนอื่นจะต้องรักษารหัสของคุณใน 3 ปี อย่าพลาด

— xaxxon

4

@xaxxon ไม่ต้องพูดถึงแอปเปิ้ลแม้ว่าบุคคลนั้นอาจเป็นคุณ

— ปุย

3

@mehaase - ไม่ใช่สิ่งที่ไม่ว่า แต่ทำไมเป็นเหตุผลสำคัญที่สุดที่จะเพิ่มความคิดเห็นในรหัส

— Henk Langeveld

1

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

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

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

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

— เบรนแดน
แหล่งที่มา

1

นี่คือส่วนขยายของคำตอบ tdammers ส่วนใหญ่ แต่ดำเนินการตรวจสอบโค้ดตามช่วงเวลาปกติ

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

แก้ไข: ฉันไม่แน่ใจว่าทำไมใครบางคนถึง downvote ข้อเสนอแนะของฉัน - บางทีฉันรับเพื่อประโยชน์ของการตรวจสอบรหัสจะเป็นความรู้ทั่วไป ... โปรดดูหัวข้อนี้เป็นการวิเคราะห์ชุมชนของการปฏิบัติ:

การตรวจสอบรหัสเป็นการปฏิบัติที่ดีหรือไม่?

— LJ2
แหล่งที่มา

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

— Evik James

1

การมีคนหัวเราะเยาะรหัสต่อหน้าเพื่อนร่วมงานคนอื่นไม่ใช่วิธีที่จะทำ: - \

— Danny Tuppeny

1

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

— Martin Brown

1

เมื่อพิจารณาถึงมุมมองที่รุนแรงในการแสดงความคิดเห็นฉันลังเลที่จะชั่งน้ำหนักการพูด ...

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

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

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

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

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

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

— เรียกเก็บเงิน
แหล่งที่มา

0

หลายโครงการต้องการเอกสารรหัส: เอกสารอินเตอร์เฟส, เอกสารการออกแบบ, ...

บางโครงการต้องการให้เอกสารดังกล่าวจะต้องใส่ความคิดเห็นของรหัสและแยกด้วยเครื่องมือเช่น Doxygen หรือ Sphinx หรือ Javadoc เพื่อให้รหัสและเอกสารให้สอดคล้องกันมากขึ้น

ด้วยวิธีนี้นักพัฒนาจะต้องเขียนความคิดเห็นที่เป็นประโยชน์ในรหัสและหน้าที่นี้รวมอยู่ในการวางแผนโครงการ

— mouviciel
แหล่งที่มา

6

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

— Jan Hudec

1

@JanHudec - ฉันเห็นด้วยกับคุณ นั่นคือเหตุผลที่ควรตั้งค่าการควบคุมบางอย่าง การสร้างอัตโนมัติช่วยให้มั่นใจได้ว่าเช่นอาร์กิวเมนต์ของฟังก์ชันในโค้ดนั้นเหมือนกับในความคิดเห็น ยิ่งกว่านั้นการมี PDF หนึ่งไฟล์แทนที่จะเป็นไดเรกทอรีของไฟล์ต้นฉบับทำให้เอกสารอ่านได้ง่ายขึ้น (เช่นวิจารณ์ได้มากขึ้น) โดยคนจำนวนมากขึ้น

— mouviciel

2

ก็ไม่เป็นไร คุณจะสังเกตได้อย่างไรในไฟล์. pdf ว่าโค้ดทำอะไรที่แตกต่างไปจากที่อธิบายไว้อย่างละเอียด?

— Jan Hudec

1

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

— mouviciel

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

— Jan Hudec

0

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

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

— reinierpost
แหล่งที่มา

0

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

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

   var str1:String="" //not uderstandable
   var strSearchPattern:String="" //uderstandable

— M.S.Nayak
แหล่งที่มา

0

ชอบคำตอบตรวจสอบโค้ด แต่บางทีกระบวนการของฉันอาจช่วยได้เช่นกัน

ฉันชอบความคิดเห็น แต่ฉันแทบจะไม่เคยเพิ่มลงในรหัสเมื่อผ่านครั้งแรก บางทีมันอาจเป็นสไตล์ของฉัน แต่ฉันจะตีส่วนที่เหมือนกันของโค้ด 3 ถึง 5 เท่าระหว่างการพัฒนา (การรีแฟคเตอร์การทดสอบการเขียน ฯลฯ )

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

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

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

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

— บิลเค
แหล่งที่มา

0

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

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

ไม่มีอาจารย์ที่ดีไปกว่าประสบการณ์ที่โหดร้าย!

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

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

— GordonM
แหล่งที่มา

-1

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

— Abhishek Gahlout
แหล่งที่มา

12

ฉันเพิ่งจะหลีกเลี่ยงปุ่ม -1 บนนี้ รหัสส่วนใหญ่ที่ฉันเขียนมีความคิดเห็นน้อยมาก ฉันไม่คิดว่าฉันมีคนบ่นว่าอย่างน้อยก็ไม่เข้าใจในช่วงหลายปีที่ผ่านมา ด้วยข้อยกเว้นน้อยมากหากรหัสต้องการความคิดเห็นที่จะเข้าใจแล้วมันไม่จำเป็นต้องแสดงความคิดเห็นก็ต้องมีการปรับปรุงเพื่อความชัดเจน (แน่นอนคุณต้องเข้าใจพื้นฐานของไวยากรณ์ของภาษาสิ่งต่าง ๆ เช่นใน C ++ อย่าออกนอกเส้นทางของคุณเพียงเพื่อหลีกเลี่ยงการใช้reinterpret_cast<>()เพราะคนอาจพบว่ามันสับสนใน C # ถ้า??คุณต้องการใช้ มัน ฯลฯ )

— CVn

2

@ MichaelKjörling: มันขึ้นอยู่กับว่าคุณเขียนโค้ดแบบไหน หากรหัสของคุณขึ้นอยู่กับลักษณะที่ผิดปกติของภาษาหรือ API หรือคุณทำบางสิ่งด้วยวิธีการตอบโต้เพื่อหลีกเลี่ยงบั๊กที่คลุมเครือซึ่งใช้เวลาหลายชั่วโมงในการค้นพบมันจะมีประสิทธิภาพมากขึ้นในการแสดงความคิดเห็นเกี่ยวกับ มัน (อาจรวมถึงการเชื่อมโยงไปยังบทความ) กว่าที่จะพยายามทำให้รหัส "ชัดเจน" เกี่ยวกับข้อมูลพื้นฐานนี้โดยไม่มีความคิดเห็น

— LarsH

@ MichaelKjörling: ฉันมีแรงบันดาลใจเป็นพิเศษที่จะพูดในวันนี้เพราะฉันได้มวยปล้ำมาหลายเดือนแล้วด้วย GIS API ที่ลึกซึ้ง สิ่งอำนวยความสะดวกของ API นั้นซับซ้อนและไม่มีการจัดทำเป็นเอกสารอย่างละเอียดมากนัก เราพบเจอกับความประหลาดใจอย่างต่อเนื่องซึ่งบางครั้งก็ทำให้เราย้อนกลับไปในแต่ละวัน การคาดหวังให้คนอื่น (หรือฉันภายใน 6 เดือน) ต้องค้นพบนักเก็ตเหล่านั้นใหม่เพื่อที่จะทำงานได้อย่างมีประสิทธิภาพด้วยรหัสของเราจะเป็นการเสียเวลามหาศาลของบุคคลนั้น และโดยทั่วไปความลับเหล่านั้นไม่สามารถจัดทำเป็นเอกสารโดยไม่แสดงความคิดเห็น "การปรับปรุงเพื่อความชัดเจน"

— LarsH

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

— CVn

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

— LarsH

-1

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

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

— Arkh
แหล่งที่มา

1

วิธีนี้มีแนวโน้มที่จะทำให้โปรแกรมเมอร์เลิกแทนที่จะฝึกอบรมพวกเขาในวิธีที่เหมาะสมในการทำสิ่งต่าง ๆ

— Martin Brown

-1

ในหนึ่งในโครงการที่ผ่านมาของฉันหายไปหลายสิบความคิดเห็น (อัลกอริทึมผลลัพธ์หรือ JavaDoc พื้นฐาน) ดังนั้นฉันเพิ่งตัดสินใจที่จะสร้างปัญหาให้กับเขา 130 เรื่องการแจ้งเตือนทางอีเมลเกี่ยวกับแต่ละประเด็นทุก 4 วัน หลังจาก 3 สัปดาห์เขามีปัญหาถึง 280 ครั้งเขาจึงตัดสินใจเขียนความคิดเห็น

— agilob
แหล่งที่มา

-1

ความคิดเห็นมีจุดประสงค์เดียวและจุดประสงค์เดียวเท่านั้น:

ทำไมรหัสนี้ทำสิ่งนี้

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

ฉันมีนิสัยชอบที่จะแสดงความคิดเห็นในสิ่งที่ชัดเจนที่สุดใน IDE ของฉัน พวกเขาจะเน้นด้วยข้อความสีขาวบนพื้นหลังสีเขียว ดึงดูดความสนใจของคุณจริงๆ

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

ตัวอย่างที่ดีของความคิดเห็น:

/* Must instantiate clsUser before trying to encrypt a password because the code to 
   encrypt passwords only uses strong encryption if that module is loaded. */

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

/* instantiate clsUser */

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

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

หากคุณใช้ความคิดเห็นเป็นข้อความเตือน:ตรวจสอบให้แน่ใจว่าคุณพูดว่าทำไม

— โจนาธาน
แหล่งที่มา

-2

เพื่อเสริมคำตอบที่นี่ฉันอาจเพิ่ม "ถ้าคุณต้องการมันถูกต้องคุณต้องทำด้วยตัวเอง"

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

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

— M. ดัดลีย์
แหล่งที่มา

1

ฉันยืนยันว่าการแสดงโค้ดที่สะอาดกว่า / การเปลี่ยนรหัสใหม่ให้อ่านง่ายขึ้นแสดงให้เห็นถึงการเปลี่ยนแปลงที่ยิ่งใหญ่กว่าการใส่ความคิดเห็นลงในโค้ด

— Makoto

ใครช่วยอธิบายสิ่งที่พวกเขาไม่ชอบเกี่ยวกับความคิดของฉัน ...

— M. Dudley

-6

ง่าย: หากพนักงานไม่แสดงความคิดเห็นบอกให้เขากดshift+alt+jความคิดเห็นอัตโนมัติในแต่ละวิธีพร้อมกันโดยป้อนรหัส โปรดแก้ไขรหัสเพื่อหลีกเลี่ยงปัญหาเหล่านี้

— เตอร์
แหล่งที่มา

11

"ความคิดเห็นอัตโนมัติ"? ดังนั้นที่ที่ทุกคน "เพิ่มฉันโดยที่ 1" ความเห็นจะมาจากไหน? IDE ชนิดใดที่ใช้ (เพื่อให้ฉันสามารถหลีกเลี่ยงงานที่กำลังใช้งานอยู่)

— CVn

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

— TRiG