ควรเขียนข้อความในปัจจุบันหรือในอดีต? [ปิด]


102

คุณคิดว่าแบบไหนดีกว่าและใช้งานง่ายกว่ากัน?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

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


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

1
ไม่หลอกลวงคำถามนั้น นี่เป็นการถามเกี่ยวกับแง่มุมเล็ก ๆ อย่างหนึ่งไม่ใช่แนวทางโดยรวม

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

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

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

คำตอบ:


39

ฉันนึกถึงข้อความเหล่านี้เหมือนที่ปรากฏต่อนักพัฒนาซอฟต์แวร์คนอื่น ๆ พวกเขายังไม่ได้นำการเปลี่ยนแปลงไปใช้และมีคำถามโดยปริยายว่า "จะใช้ชุดการเปลี่ยนแปลง / โปรแกรมแก้ไขนี้ทำอะไร" มันจะ "แก้ไขข้อบกพร่องของ XXX ในปปปป"!

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

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


8
ฉันจำได้ว่าเจอบางอย่างในเอกสารคอมไพล์ที่แนะนำอย่างยิ่งเกี่ยวกับเรื่องนี้ แต่ฉันก็ยังรู้สึกอึดอัด
keithjgrant

1
นี่คือส่วนหนึ่งของเอกสาร Git ที่มาจาก
sschuberth

31

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


คุณสามารถยกตัวอย่างนี้ได้หรือไม่?
bzlm

15
ตัวอย่างนี้
สาธุคุณกอนโซ

เรียกว่า 'Commit History' ประวัติศาสตร์มักเขียนในอดีตกาลเสมอ อดีตกาลจึงเข้าท่ากว่า เมื่อคุณกำลังดูประวัติการกระทำของ repo คุณกำลังดูสิ่งที่ทำกับมัน ... ในอดีต!
พระศิวะ

13

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

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


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

9

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

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

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


7
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

โดยทั่วไป: {คำกริยาที่จำเป็น} {วัตถุที่ได้รับผลกระทบ} {ตัวเลือกคุณสมบัติเสริม}

แบบฟอร์มที่จำเป็นเหมาะกับทุกกรณีการใช้งานเมื่อฉันกำลังพิจารณาชุดแพทช์

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

ไม่ว่าคุณจะเลือกแบบใดฉันพบว่าความสม่ำเสมอช่วยให้อ่านได้อย่างมาก เลือกหนึ่งและติดมัน


4
เหตุผลที่ดีมาก ฉันมักจะคิดว่าข้อความนั้นบอกว่า "ฉันเป็นแพทช์และฉัน [ข้อความ]" ด้วยวิธีนี้คุณจะเริ่มต้นด้วยคำกริยาที่จำเป็นเสมอ
florisla

5

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


1
ฉันเห็นด้วย. หากการกระทำนั้นอ้างถึงตัวมันเองก็เป็นจริงเช่นกันเช่นใน "การกระทำนี้แก้ไขข้อบกพร่อง F00F"
bzlm

4

ฉันไม่คิดว่ามันสำคัญจริงๆ มีวัตถุประสงค์เพื่อ:

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

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

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


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

1
ฉันคิดว่ามันสำคัญถ้าข้อความสั้นเกินไป บางครั้งฉันเห็นข้อความคอมมิตที่ทำให้ฉันสงสัยว่า 1. พบข้อบกพร่องหรือได้รับการแก้ไขจริงหรือ 2. การแก้ไขได้รับการสรุปหรือนำไปใช้จริงหรือ 3. พฤติกรรมที่ผิดพลาดที่ซับซ้อนได้รับการแก้ไขบางส่วนหรือทั้งหมดจริงหรือไม่ และบางครั้งการกระทำหลายครั้งก็เกี่ยวข้องกับข้อบกพร่องเดียวกัน ใน "การกระทำนี้ช่วยแก้ไขปัญหาการตีกลับใน DrawBall () และปิดตั๋ว 666" Tense ไม่สำคัญเพราะข้อความเป็นแบบละเอียด แต่สำหรับ "DrawBall () ตีกลับผิด" การกระทำนี้ทำอย่างไร
bzlm

2

" แก้ไขข้อบกพร่อง X " สั้นกว่า " แก้ไขข้อบกพร่อง X " 2 ตัว
และสั้นกว่า " Fixing bug X " 3 อัน

จากมุมมองของการเขียนข้อความสั้น ๆ ปัจจุบันกาลบางครั้ง / มักจะบันทึกอักขระไม่กี่ตัว?
ซึ่งจริงๆแล้วฉันคิดว่ามีความสำคัญเล็กน้อยเช่นด้วยคำแนะนำของ Git ที่มีข้อความน้อยกว่า 50 ตัวอักษรบนบรรทัดแรกคอมมิตข้อความ
นอกจากนี้ข้อความน้อยลง -> อ่านเสร็จเร็วขึ้นหรือไม่?


1

ข้อความคอมมิตจะอธิบายถึงสาเหตุที่คุณเขียนโค้ดที่ถูกคอมมิต

"แก้ไขปัญหา 3124" หรือ "แก้ไขปัญหา 3124" ดูเหมือนถูกต้องเพราะระบุว่ารหัสนี้แก้ไขแล้ว | แก้ไขปัญหา 3124

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


0

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

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

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

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


-1

ฉันคิดว่า"Fixes XXX bug"มีเหตุผลมากกว่า"Fix XXX bug"ถ้าเหตุผลในการใช้กาลปัจจุบันคือการ"ทำให้สื่อความหมายถึงสิ่งที่กระทำ"มากกว่าสิ่งที่ผู้กระทำทำ


-4

หากเป็นการกระทำเล็กน้อยฉันใช้ present continuous:

แก้ไขข้อบกพร่อง 304

หรือ

การเพิ่มความคิดเห็น

หากเป็นการกระทำครั้งใหญ่ฉันทำบันทึกการเปลี่ยนแปลงเพิ่มเติม:

  • แก้ไข Bug 453, 657 และ 324
  • การเพิ่มไวยากรณ์ของนิพจน์
  • ปรับโครงสร้างคลาส Operator ใหม่

9
กล่าวอีกนัยหนึ่งคุณผสมทั้งหมดโดย
เต็มใจ

สวยมาก. เพราะท้ายที่สุดแล้วข้อความคอมมิตไม่จำเป็นต้องเป็นภาษาอังกฤษของราชินี
tster

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