คุณติดตามผู้เขียนรหัสได้อย่างไร [ปิด]


14

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

ฉันมักจะไป

@author garbagecollector
@company garbage inc.

3
บุคคลที่เปลี่ยนรหัสของคุณอยู่ที่ไหน
JeffO

@ เจฟฟ์มันดูที่ไหนและอย่างไร
dustyprogrammer

มันไม่มีเหตุผลที่จะทำเช่นนั้น ทำไมคุณต้องการทำเช่นนั้น?
CodeART

คำตอบ:


-1

ไม่แน่ใจว่าสิ่งที่คุณถาม แต่ฉันใช้สไตล์ที่เข้มงวดมาก:

;==========================================
; Title:  Author Style Sample
; Author: Darknite
; Date:   7 Jan 2011
;==========================================

ลักษณะเป็นแรงบันดาลใจจากโปรแกรมเมอร์ประกอบ

ฉันวางไว้ที่ด้านบนของหน้าฉันต้อง "ผู้เขียน" โดยไม่คำนึงว่านี่เป็นคลาสไฟล์ข้อความหรือ SQL ขั้นตอนการจัดเก็บ ฯลฯ


นี่คือสิ่งที่ฉันกำลังมองหา
dustyprogrammer

5
-1 สิ่งนี้ (ซึ่งเติบโตขึ้นมากหากอัปเดต (ทั้งมันและการเปลี่ยนแปลงรหัสโดยคนต่าง ๆ ) จะถูกแทนที่อย่างมีประสิทธิภาพด้วยการควบคุมเวอร์ชัน
Michael Durrant

1
@MichaelDurrant คุณลืมปิดวงเล็บของคุณ;) เจ๋งอยู่ดี ฉันชอบนกเพนกวิน
Darknight

4
@Giorgio ไม่จริง ... อาจไม่มีรหัสบรรทัดเดียวของผู้เขียนต้นฉบับที่เหลืออยู่ในไฟล์ มันไม่มีจุดหมาย
Wilbert

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

71

ทำไมคุณ นั่นคือหน้าที่ของระบบการกำหนดเวอร์ชันและ "Blame" :)


8
การควบคุมเวอร์ชัน ftw
พอลนาธา

1
หากคุณคิดว่ามันเป็นการจัดการซอร์สโค้ด (SCM) แทนที่จะเป็นระบบควบคุมเวอร์ชัน (VCS)
Peter Eisentraut

ข้อ จำกัด เล็ก ๆ น้อย ๆ การเปลี่ยนแปลงเครื่องสำอาง (เยื้องและอื่น ๆ ... ) เปลี่ยนผู้เขียนบรรทัด ...
Matthieu M.

4
@ Matthieu: SCM ที่ดีสามารถแสดงให้เห็นว่าใครทำอะไรเปลี่ยนแปลงตลอดเวลาไม่ใช่แค่คนสุดท้ายที่จะสัมผัส ฉันอาจจะโต้แย้งว่าการเปลี่ยนแปลงเครื่องสำอางนั้นก็มีการเปลี่ยนแปลงเช่นกัน
grossvogel

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

11

เราไม่ได้เขียนที่ บริษัท ของฉัน เราปล่อยให้การควบคุมเวอร์ชันของเราจัดการแทน

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

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


10

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

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


6

JavaDoc เป็นมาตรฐานที่สำคัญมากในชุมชน Java:

http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html#@author

@author ชื่อข้อความ

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


5

ฉันคิดว่านั่นเป็นสิ่งที่ดีที่สุดสำหรับระบบควบคุมเวอร์ชัน


4

ฉันชอบคุณสมบัติตำหนิใน GIT คุณสามารถดูว่าใครเขียนรหัสแต่ละชิ้น / บรรทัด ไม่ใช่แค่ไฟล์


VCS อื่นมีสิ่งเดียวกัน (แม้ว่ามักจะไม่เรียกว่า "ตำหนิ")
ริชาร์ด

ฉันจะ -1 นี่เพราะมันเป็น GIT ที่เฉพาะเจาะจง OP ไม่เคยกล่าวถึง GIT แต่อนิจจาฉันไม่มีตัวแทนเพียงพอที่จะลงคะแนน
Thomas Eding

2

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

คำถามเหล่านี้ดีกว่าสำหรับระบบควบคุมเวอร์ชัน

แต่ฉันไม่ได้ต่อต้านรายชื่อผู้แต่ง การเก็บรายชื่อผู้แต่งสำหรับโครงการทั้งหมดนั้นสมเหตุสมผลดี หากเป็นโครงการไฟล์เดียวให้เก็บไว้ในไฟล์นั้นมาก หากเป็นโครงการขนาดใหญ่ให้เก็บไว้ใน README หรือไฟล์ต้นฉบับระดับบนสุด (aka main.c) แต่อย่าทำซ้ำตัวคุณเองด้วยรายชื่อผู้แต่งในทุก ๆ ไฟล์


1

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


0

ฉันใช้ความคิดเห็นสไตล์Doxygen (หรือบางครั้ง KernelDoc) สำหรับทุกอย่างสวยมาก ฉันส่วนใหญ่ทำงานใน C และ PHP ที่ Doxygen เป็นที่นิยมมาก

ในกรณีส่วนใหญ่จะเป็นประโยชน์อย่างน้อยรวมถึงข้อมูลต่อไปนี้:

  • การอนุญาต (หรือไม่) เพื่อคัดลอก / ลิขสิทธิ์ของ บริษัท หรือบุคคล
  • ชื่อผู้แต่ง / อีเมล
  • วันที่เขียน
  • วันที่แก้ไขล่าสุด

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


0

ฉันไม่ได้ทำแบบนี้เป็นการส่วนตัวเพราะมันเป็นเอกสารพิเศษที่คนอื่นพูดว่าอยู่ในการควบคุมเวอร์ชัน แต่ถ้าฉันจะสร้างโค้ด snippit ของกังฟูบางอย่างฉันอาจจะไปกับอะไรก็ตามที่ IDE ของฉันสามารถสร้างได้โดยอัตโนมัติ

ตัวอย่างเช่นการใช้ใน Delphi 7 ที่ติดตั้ง CNTools ที่เป็นประโยชน์เหล่านั้นฉันพิมพ์

///a [enter]

และออกมา

//<author></author>

จากนั้นฉันพิมพ์

///d [enter]

และออกมา

 //<date></date>

ฉันนึกภาพที่สอดคล้องกับสิ่งที่ยูทิลิตี้ของบุคคลที่สามสามารถรับได้ แต่สำหรับฉัน - ฉันมีมาตรฐานที่ฉันไม่ต้องแต่งหน้าและทำให้เสียหาย

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