คำถามติดแท็ก comments

ฉันกำลังมองหาคำแนะนำวิธีปฏิบัติที่ดีที่สุดสำหรับความคิดเห็น XML ใน C # เมื่อคุณสร้างคุณสมบัติดูเหมือนว่าเอกสาร XML ที่ต้องการมีรูปแบบดังต่อไปนี้: /// <summary> /// Gets or sets the ID the uniquely identifies this <see cref="User" /> instance. /// </summary> public int ID { get; set; } แต่เนื่องจากลายเซ็นของสถานที่ให้บริการจะบอกคุณว่าการดำเนินงานที่มีให้กับลูกค้าภายนอกของชั้นเรียน (ในกรณีนี้มันเป็นทั้งสองgetและset) ฉันรู้สึกเหมือนความคิดเห็นที่ช่างพูดเกินไปและอาจจะพอดังต่อไปนี้: /// <summary> /// ID that uniquely identifies this <see cref="User" /> instance. /// </summary> …

19 c#  .net  programming-practices  comments 

ผมเห็นตัวเลขปัญหามากมายจากความคิดเห็นของรหัส jQuery (ที่จริงแล้วมีปัญหา 69 รายการในรหัส jQuery) ฉันคิดว่ามันจะเป็นแนวปฏิบัติที่ดี แต่ฉันไม่เคยเห็นแนวทางใด ๆ หากเป็นการปฏิบัติที่ดีแนวทางในการฝึกนี้คืออะไร?

18 comments  issue-tracking 

ไม่กี่คนที่ทำ แต่ไม่ได้รับความนิยมเท่าที่ฉันรู้ มีบางอย่างที่ไม่ดีเกี่ยวกับความคิดเห็นในการซ้อนหรือไม่ ฉันวางแผนที่จะบล็อกความคิดเห็นซ้อนในภาษา (เล็ก) ที่ฉันกำลังทำงานอยู่ แต่ฉันอยากจะรู้ว่านี่เป็นความคิดที่ไม่ดีหรือไม่

18 language-agnostic  syntax  comments 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันมักจะเห็นความคิดเห็นดังกล่าวจะใช้: function foo() { ... } // foo while (...) { ... } // while if (...) { ... } // if และบางครั้งก็ถึงเท่าที่ if (condition) { ... } // if (condition) ฉันไม่เคยเข้าใจแบบฝึกหัดนี้เลยจึงไม่เคยใช้มันเลย หากรหัสของคุณยาวจนคุณต้องรู้ว่าจุดสิ้นสุดนี้}คืออะไรบางทีคุณควรพิจารณาแยกมันออกเป็นฟังก์ชั่นแยกต่างหาก นอกจากนี้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ส่วนใหญ่สามารถข้ามไปยังวงเล็บเหลี่ยมที่ตรงกันได้ และสุดท้ายสิ่งสุดท้ายคือสำหรับฉันการละเมิดหลักการ DRY อย่างชัดเจน หากคุณเปลี่ยนเงื่อนไขคุณจะต้องจำไว้ว่าให้เปลี่ยนความคิดเห็นเช่นกัน (หรืออื่น ๆ มันอาจทำให้ยุ่งสำหรับผู้ดูแลหรือแม้แต่สำหรับคุณ) เหตุใดผู้คนจึงใช้สิ่งนี้ เราควรใช้มันหรือเป็นการฝึกฝนที่ไม่ดี?

18 source-code  comments 

ผู้พัฒนาระดับสูงในร้านของเรายืนยันว่าเมื่อใดก็ตามที่มีการแก้ไขโค้ดโปรแกรมเมอร์ที่รับผิดชอบควรเพิ่มความคิดเห็นแบบอินไลน์ที่ระบุสิ่งที่เขาทำ ความคิดเห็นเหล่านี้มักจะดูเหมือน// YYYY-MM-DD <User ID> Added this IF block per bug 1234. เราใช้ TFS เพื่อควบคุมการแก้ไขและฉันคิดว่าความคิดเห็นของการเรียงลำดับนี้มีความเหมาะสมมากขึ้นในฐานะบันทึกการเช็คอินแทนที่จะเป็นเสียงอินไลน์ TFS ยังให้คุณเชื่อมโยงการเช็คอินกับบั๊กตั้งแต่หนึ่งข้อขึ้นไป ไฟล์คลาสที่เก่าและมีการแก้ไขบ่อยครั้งของเราบางคนดูเหมือนว่าพวกเขามีอัตราส่วนความคิดเห็นต่อ LOC ใกล้ถึง 1: 1 ในสายตาของฉันความคิดเห็นเหล่านี้ทำให้รหัสยากต่อการอ่านและเพิ่มค่าเป็นศูนย์ นี่เป็นวิธีปฏิบัติที่เป็นมาตรฐาน (หรืออย่างน้อยสามัญ) ในร้านค้าอื่นหรือไม่?

17 coding-standards  comments 

หนึ่งในทีมของฉันเชื่อว่าจำเป็นต้องเขียนความคิดเห็น javadoc สำหรับพารามิเตอร์ EVERY ในลายเซ็นของเมธอด ฉันไม่คิดว่ามันเป็นสิ่งจำเป็นและอันที่จริงฉันคิดว่ามันอาจเป็นอันตรายได้ ก่อนอื่นฉันคิดว่าชื่อพารามิเตอร์ควรเป็นคำอธิบายและจัดทำเอกสารด้วยตนเอง หากไม่ชัดเจนว่าพารามิเตอร์ของคุณเป็นอย่างไรคุณอาจทำผิด อย่างไรก็ตามฉันเข้าใจว่าบางครั้งมันก็ไม่ชัดเจนว่าพารามิเตอร์สำหรับดังนั้นในกรณีเหล่านั้นใช่คุณควรเขียนความคิดเห็น javadoc อธิบายพารามิเตอร์ แต่ฉันคิดว่ามันไม่จำเป็นที่จะทำเช่นนั้นสำหรับพารามิเตอร์ทุกคน หากเห็นได้ชัดว่าพารามิเตอร์สำหรับความคิดเห็น javadoc นั้นซ้ำซ้อน; คุณกำลังสร้างงานพิเศษสำหรับตัวคุณเอง นอกจากนี้คุณกำลังสร้างงานพิเศษสำหรับทุกคนที่ต้องรักษารหัสของคุณ วิธีการเปลี่ยนแปลงเมื่อเวลาผ่านไปและการบำรุงรักษาความคิดเห็นเกือบจะสำคัญเท่ากับการบำรุงรักษาโค้ดของคุณ มีกี่ครั้งที่คุณเห็นความคิดเห็นเช่น "X ทำ Y เพื่อ Z เหตุผล" เพียงเพื่อดูว่าความคิดเห็นนั้นล้าสมัยและในความเป็นจริงวิธีการไม่ได้ใช้พารามิเตอร์ X อีกต่อไป? มันเกิดขึ้นตลอดเวลาเพราะคนลืมที่จะอัพเดทความคิดเห็น ฉันจะยืนยันว่าความคิดเห็นที่ทำให้เข้าใจผิดเป็นอันตรายมากกว่าความคิดเห็นที่ไม่ทั้งหมด และดังนั้นจึงเป็นอันตรายของการแสดงความคิดเห็นมากเกินไป: โดยการสร้างเอกสารที่ไม่จำเป็นคุณจะต้อง อย่างไรก็ตามฉันเคารพนักพัฒนาคนอื่นในทีมของฉันและยอมรับว่าบางทีเขาอาจจะพูดถูกและฉันผิด ทำไมฉันถึงนำคำถามมาให้คุณผู้พัฒนาเพื่อน: จำเป็นต้องเขียนความคิดเห็น javadoc สำหรับพารามิเตอร์ EVERY หรือไม่? สมมติว่านี่เป็นรหัสภายใน บริษัท ของฉันและบุคคลภายนอกใด ๆ จะไม่ถูกใช้

17 java  documentation  source-code  comments  maintainability 

ในบาง codebase คุณสามารถเห็นความคิดเห็นที่ระบุเช่น: // Workaround for defect 'xxx', (See bug 1434594 on Sun's bugparade) ดังนั้นฉันมีคำถามสองสามข้อ แต่ทั้งหมดเกี่ยวข้องกัน ตกลงหรือไม่ที่จะใส่ลิงก์ไปยังคำถาม SO ในความคิดเห็นของโปรแกรม: // We're now mapping from the "sorted-on column" to original indices. // // There's apparently no easy way to do this in Java, so we're // re-inventing a wheel. // // …

16 comments 

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

15 .net  comments  coding  exceptions 

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

15 comments 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา เมื่อใดก็ตามที่ฉันเขียนภาษาอื่นถ้าสร้างในภาษาใดฉันสงสัยว่าอะไรจะเป็นวิธีที่ดีที่สุด (ในแง่ของการอ่านและภาพรวม) เพื่อเพิ่มความคิดเห็น โดยเฉพาะอย่างยิ่งเมื่อแสดงความคิดเห็นข้ออื่นความคิดเห็นมักจะออกจากสถานที่สำหรับฉัน สมมติว่าเรามีโครงสร้างเช่นนี้ (ตัวอย่างถูกเขียนลงใน PHP): if ($big == true) { bigMagic(); } else { smallMagic() } ฉันสามารถแสดงความคิดเห็นได้เช่นนี้ // check, what kind of magic should happen if ($big == true) { // do some big magic stuff bigMagic(); } else { …

15 comments 

ฉันกำลังมองหารูปแบบเอกสารข้อมูลระดับสำหรับ Entity, Business Logic และคลาส Data Access ของฉัน ฉันพบรูปแบบสองรูปแบบจากที่นี่ รูปแบบ 1 ///----------------------------------------------------------------- /// Namespace: <Class Namespace> /// Class: <Class Name> /// Description: <Description> /// Author: <Author> Date: <DateTime> /// Notes: <Notes> /// Revision History: /// Name: Date: Description: ///----------------------------------------------------------------- รูปแบบ 2 // =============================== // AUTHOR : // CREATE DATE : …

15 c#  documentation  comments 

พิจารณาเครื่องหมายความขัดแย้ง เช่น: <<<<<<< branch blah blah this ======= blah blah that >>>>>>> HEAD ในกรณีเฉพาะที่กระตุ้นให้ฉันโพสต์คำถามนี้สมาชิกในทีมที่รับผิดชอบเพิ่งจะทำการผสานตั้งแต่ต้นน้ำจนถึงสาขาของเราและในบางกรณีก็ทิ้งสิ่งเหล่านี้ไว้ในความคิดเห็นเป็นเอกสารประกอบสิ่งที่เพิ่งเกิดขึ้น การแก้ไข เขาทิ้งไว้ในสถานะที่รวบรวมการทดสอบผ่านดังนั้นจึงไม่เลวร้ายอย่างที่คุณคิด โดยสัญชาตญาณแม้ว่าฉันจะคัดค้านเรื่องนี้จริง ๆ แต่เป็นมารสนับสนุนให้ตัวเองฉันสามารถดูว่าทำไมเขาอาจทำ: เพราะมันเน้นไปที่นักพัฒนาทีมคนอื่น ๆ สิ่งที่มีการเปลี่ยนแปลงอันเป็นผลมาจากการรวม เพราะผู้ที่มีความเชี่ยวชาญมากขึ้นในส่วนของรหัสสามารถแก้ไขข้อกังวลที่แสดงโดยข้อคิดเห็นเพื่อที่เขาจะได้ไม่ต้องเดา เนื่องจากการรวมอัปสตรีมเป็นความเจ็บปวดที่ถูกต้องและอาจเป็นเรื่องยากที่จะพิสูจน์เวลาในการแก้ไขทุกอย่างให้ดีและสมบูรณ์ดังนั้นการแจ้งเตือน FIXME แบบกึ่งสมบูรณ์จึงมีความจำเป็นดังนั้นทำไมไม่ใช้ความขัดแย้งเดิมเป็นความคิดเห็น การคัดค้านของฉันเป็นสัญชาตญาณ แต่ฉันต้องการที่จะพิสูจน์เหตุผลอย่างมีเหตุผลหรือเห็นตำแหน่งของฉันอย่างชาญฉลาด ทุกคนสามารถให้ฉันตัวอย่างหรือประสบการณ์ที่ผู้คนมีช่วงเวลาที่เลวร้ายกับคนอื่นทำเช่นนี้และ / หรือเหตุผลที่ว่าทำไมมันถึงเป็นการปฏิบัติที่ไม่ดี (หรือคุณสามารถเล่นผู้สนับสนุนของปีศาจและสนับสนุนมัน) ข้อกังวลของฉันเองในทันทีคือมันจะน่ารำคาญถ้าฉันได้แก้ไขไฟล์ใดไฟล์หนึ่งที่เกี่ยวข้องดึงการเปลี่ยนแปลงมีความขัดแย้งจริง แต่ก็ดึงความคิดเห็น ถ้าอย่างนั้นฉันจะมีไฟล์ยุ่งมากแน่นอน โชคดีที่ไม่ได้เกิดขึ้น

14 version-control  comments  coding-style 

ฉันเขียนโค้ด (c ++ และ javascript) เป็นจำนวนมากซึ่งสัมผัสกับเรขาคณิตและกราฟิกการคำนวณและหัวข้อเหล่านั้นดังนั้นฉันจึงพบว่าไดอะแกรมภาพนั้นเป็นส่วนที่ขาดไม่ได้ของกระบวนการแก้ปัญหา ฉันได้ตัดสินใจแล้วว่า "โอ้ไม่น่าอัศจรรย์ถ้าฉันสามารถแนบแผนภาพวาดด้วยมือกับชิ้นส่วนของรหัสเพื่อแสดงความคิดเห็น" และนี่จะทำให้ฉันกลับมามีบางสิ่งที่ฉันทำ วัน, สัปดาห์, เดือนก่อนหน้านี้และไกลโพ้นอัลกอริทึมของฉันอีกครั้งอย่างรวดเร็ว ในฐานะผู้เรียนรู้ภาพฉันรู้สึกว่าสิ่งนี้มีศักยภาพในการปรับปรุงประสิทธิภาพการทำงานของฉันด้วยการเขียนโปรแกรมเกือบทุกประเภทเนื่องจากแผนภาพง่าย ๆ สามารถช่วยให้เข้าใจและให้เหตุผลเกี่ยวกับโครงสร้างข้อมูลที่ไม่สำคัญ กราฟตัวอย่าง ในระหว่างชั้นเรียนทฤษฎีกราฟที่มหาวิทยาลัยฉันสามารถเข้าใจความสัมพันธ์ของกราฟที่จริง ๆ แล้วฉันสามารถวาดภาพตัวแทนของแผนภาพ ดังนั้น... ไม่มี IDE ให้ความรู้ของฉันช่วยให้คุณบันทึกภาพเป็นความคิดเห็นในการรหัส ความคิดของฉันคือการที่ฉันหรือคนอื่นสามารถใช้เครื่องมือที่ใช้งานง่ายพอสมควรซึ่งสามารถแปลงรูปภาพให้เป็นสตริงไบนารีพื้นฐาน 64 ซึ่งฉันสามารถแทรกลงในรหัสของฉันได้ หากกระบวนการแปลง / แทรกสามารถเพิ่มความคล่องตัวได้มากพอจะทำให้สามารถเชื่อมต่อระหว่างไดอะแกรมและรหัสจริงได้ดีกว่าดังนั้นฉันไม่จำเป็นต้องค้นหาตามลำดับเวลาในโน้ตบุ๊คของฉันอีกต่อไป น่าประทับใจยิ่งกว่า: ปลั๊กอินสำหรับ IDE ในการแยกวิเคราะห์และแสดงภาพโดยอัตโนมัติ ไม่มีอะไรยากเกี่ยวกับสิ่งนี้จากมุมมองทางทฤษฎี ฉันเดาว่ามันจะใช้เวลาเพิ่มสำหรับฉันที่จะคิดออกว่าจะขยาย IDEs ที่ชื่นชอบและดูแลปลั๊กอินเหล่านี้ได้อย่างไรดังนั้นฉันจึงมีความสุขกับโค้ดโพสต์โปรเซสเซอร์ซึ่งจะแยกวิเคราะห์และ การเรนเดอร์รูปภาพและแสดงภาพแบบเคียงข้างกันด้วยโค้ด, ภายในเบราว์เซอร์หรือบางสิ่งบางอย่าง ตั้งแต่ฉันเป็นโปรแกรมเมอร์จาวาสคริปต์โดยการค้า คนอื่นคิดอย่างไร ใครบ้างที่จ่ายสำหรับสิ่งนี้ ฉันจะ แต่บางทีฉันอาจจะชี้ให้เห็นว่าไม่ว่าฉันหรือเพื่อนร่วมงานจำนวนมากของฉันจะจ่ายเงินสำหรับสิ่งนั้นวิธีเดียวที่สิ่งนั้นมีแนวโน้มที่จะประสบความสำเร็จก็คือผ่านการเปิดตัวโอเพนซอร์ส

14 productivity  code-reviews  comments  workflows  image-manipulation 

เรากำลังทำการปรับเปลี่ยนบางอย่างให้เป็น codebase เก่าแก่อายุ 20 ปีและฉันกำลังพูดคุยกับเพื่อนร่วมงานของฉันเกี่ยวกับรูปแบบความคิดเห็นในรหัส (plsql, java) ไม่มีรูปแบบเริ่มต้นสำหรับความคิดเห็น แต่ในกรณีส่วนใหญ่คนทำสิ่งนี้ในความคิดเห็น: // date (year, year-month, yyyy-mm-dd, dd/mm/yyyy), (author id, author name, author nickname) and comment รูปแบบที่เสนอสำหรับความคิดเห็นในอนาคตและในอดีตที่ฉันต้องการคือ: // {yyyy-mm-dd}, unique_author_company_id, comment เพื่อนร่วมงานของฉันบอกว่าเราต้องการเพียงความคิดเห็นเท่านั้นและต้องจัดรูปแบบความคิดเห็นทั้งในอดีตและอนาคตในรูปแบบนี้: // comment ข้อโต้แย้งของฉัน: ฉันพูดด้วยเหตุผลด้านการบำรุงรักษาสิ่งสำคัญคือต้องรู้ว่าเมื่อใดและใครทำการเปลี่ยนแปลง (แม้ข้อมูลนี้จะอยู่ใน SCM) รหัสกำลังมีชีวิตอยู่และด้วยเหตุนี้จึงมีประวัติ เนื่องจากไม่มีการเปลี่ยนแปลงวันที่มันเป็นไปไม่ได้ที่จะรู้ว่าเมื่อใดที่มีการเปลี่ยนแปลงเกิดขึ้นโดยไม่เปิดเครื่องมือ SCM และค้นหาในประวัติวัตถุที่ยาวนาน เนื่องจากผู้เขียนมีความสำคัญมากการเปลี่ยนแปลงของผู้เขียนมีความน่าเชื่อถือมากกว่าการเปลี่ยนแปลงของ authory เหตุผลความว่องไวไม่จำเป็นต้องเปิดและนำทางผ่านเครื่องมือ SCM ผู้คนจะกลัวที่จะเปลี่ยนบางสิ่งที่บางคนทำเมื่อ 15 ปีที่แล้วมากกว่าสิ่งที่เพิ่งถูกสร้างหรือเปลี่ยนแปลง เป็นต้น ข้อโต้แย้งของเพื่อนร่วมงานของฉัน: ประวัติอยู่ใน SCM …

13 java  c#  programming-practices  code-quality  comments 

มันเป็นสไตล์ที่ดีหรือไม่ที่จะใช้ตัวแปรท้องถิ่นที่เพิ่มเติมและไม่จำเป็นทางเทคนิคเพื่ออธิบายว่าเกิดอะไรขึ้น? ตัวอย่างเช่น: bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */); if(easyUnderstandableIsTrue) { // ... } เมื่อพูดถึงค่าโสหุ้ยทางเทคนิคฉันคาดว่าคอมไพเลอร์จะปรับแต่งบรรทัดเพิ่มนอกจากนี้ แต่มันถือว่าเป็นรหัสที่ไม่จำเป็นออกบวม? ในสายตาของฉันมันช่วยลดความเสี่ยงของความคิดเห็นเก่า

12 coding-style  comments