Làm thế nào để bạn theo dõi các tác giả của mã? [đóng cửa]


14

Đây là điều tôi chưa bao giờ được dạy. Tôi đã thấy rất nhiều loại phong cách tác giả khác nhau. Tôi viết mã chủ yếu bằng Java và Python. Tôi đã tự hỏi nếu có một phong cách tác giả tiêu chuẩn hoặc nếu mọi thứ là tự do. Ngoài ra nếu bạn trả lời, bạn có phiền khi đính kèm kiểu bạn sử dụng cho các tệp tác giả mà bạn tạo ở nhà hoặc tại nơi làm việc.

Tôi thường chỉ đi

@author garbagecollector
@company garbage inc.

3
Trường hợp người thay đổi mã của bạn đặt tên của họ?
JeffO

@Jeff ở đâu và trông như thế nào.
chương trình bụi

Nó không có ý nghĩa để làm điều đó. Tại sao bạn muốn làm điều đó?
CodeART

Câu trả lời:


-1

Không hoàn toàn chắc chắn những gì bạn đang hỏi, tuy nhiên tôi sử dụng một phong cách rất nghiêm ngặt:

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

Phong cách được lấy cảm hứng từ các lập trình viên lắp ráp.

Tôi đặt cái này ở đầu các trang tôi cần "Tác giả", bất kể đây là lớp, tệp văn bản hay thủ tục lưu trữ SQL, v.v.


Đây là dọc theo dòng của những gì tôi đang tìm kiếm.
chương trình bụi

5
-1 Cái này (sẽ phát triển rất nhiều nếu được cập nhật (cả mã và mã thay đổi bởi nhiều người khác nhau) được thay thế một cách hiệu quả bằng kiểm soát phiên bản.
Michael Durrant

1
@MichaelDurrant bạn quên đóng dấu ngoặc đơn;) dù sao thì cũng tuyệt. Tôi thích chim cánh cụt.
Darknight

4
@Giorgio Không thực sự ... có thể không có một dòng mã nào của tác giả gốc còn lại trong tệp. Nó là vô nghĩa.
Wilbert

1
@Wilbert: Tất nhiên, điều này cũng phụ thuộc vào chính sách của nhóm: với quyền sở hữu mã được chia sẻ, việc theo dõi tác giả của một tệp là vô nghĩa. Với quyền sở hữu mã riêng lẻ, điều quan trọng là phải biết ai chịu trách nhiệm cho các tệp nào.
Giorgio

70

Tại sao bạn? đó là công việc của hệ thống phiên bản và "Đổ lỗi" :)


8
kiểm soát phiên bản ftw.
Paul Nathan

1
Sẽ hợp lý hơn nếu làm theo cách đó nếu bạn nghĩ đó là quản lý mã nguồn (SCM) thay vì hệ thống kiểm soát phiên bản (VCS).
Peter Eisentraut

giới hạn nhỏ, thay đổi mỹ phẩm (thụt, v.v ...) thay đổi tác giả của dòng ...
Matthieu M.

4
@Matthieu: SCM tốt có thể cho thấy ai đã thực hiện những thay đổi theo thời gian, không chỉ là người cuối cùng chạm vào nó. Tôi cũng có thể lập luận rằng những thay đổi mỹ phẩm cũng thay đổi.
Grossvogel

1
Câu trả lời này đã hơn 8 tuổi, và không ai nhận thấy những hạn chế của nó? Nó chỉ áp dụng nếu mã nguồn tồn tại trong một VCS trong toàn bộ thời gian sử dụng (hoặc được di chuyển đúng cách)! Tuy nhiên, đôi khi rất nhiều mã nguồn mở được chuyển giữa các môi trường khác nhau, vì vậy thông tin tác giả có thể không được chuyển qua nếu nó không được ghi trực tiếp vào mã nguồn.
Doc Brown

11

Chúng tôi không làm tác giả tại công ty của tôi. Thay vào đó, chúng tôi để cho kiểm soát phiên bản của chúng tôi xử lý nó.

Mỗi khi bạn đăng ký, nó sẽ đính kèm tên người dùng của bạn vào danh sách thay đổi. Nếu một cái gì đó bị hỏng, ai đó có thể quay lại và nhìn vào lịch sử thay đổi để xem những gì đã thay đổi, khi nào và ai đã làm điều đó. Nó cũng gọn gàng nhìn vào biểu đồ sửa đổi để xem một tệp đã phát triển theo thời gian như thế nào, ai đã chạm vào nó, những dự án nào đã phân nhánh từ nó.

Vấn đề tôi thấy khi đặt thẻ tác giả vào một lớp là theo thời gian, có nhiều khả năng nhiều nhà phát triển sẽ làm việc trên lớp đó. Cập nhật, và tương tự. Đó là một bước bổ sung để cập nhật nhận xét của tác giả và các bước nhỏ thêm có xu hướng bị lãng quên rất nhiều. Do đó, nó trở nên lỗi thời một cách nhanh chóng.


10

Tôi không làm điều đó cả. Tôi nghĩ tại nơi làm việc, chúng tôi có một số mẫu được chèn vào các tệp có tên công ty và tên người dùng của người đã sửa đổi tệp lần cuối, nhưng tôi không bao giờ chú ý đến điều đó.

Nói chung, tôi không nghĩ nó thực sự quan trọng như thế nào bạn làm điều đó. Nếu bạn muốn tác giả đóng dấu các tập tin của bạn, chỉ cần chọn một phong cách nhất quán và đi với nó.


6

JavaDoc có rất nhiều tiêu chuẩn trong cộng đồng Java:

http://doad.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html#@master

@author tên văn bản

Thêm mục nhập "Tác giả" với văn bản tên được chỉ định vào tài liệu được tạo khi sử dụng tùy chọn tác giả. Một bình luận doc có thể chứa nhiều @authorthẻ. Bạn có thể chỉ định một tên cho mỗi @authorthẻ hoặc nhiều tên cho mỗi thẻ. Trong trường hợp trước, Javadoc chèn dấu phẩy (,) và khoảng trắng giữa các tên. Trong trường hợp sau, toàn bộ văn bản chỉ được sao chép vào tài liệu được tạo mà không bị phân tích cú pháp. Do đó, sử dụng nhiều tên trên mỗi dòng nếu bạn muốn phân tách tên được bản địa hóa ngoài dấu phẩy.


5

Tôi nghĩ rằng đó là tốt nhất để lại cho hệ thống kiểm soát phiên bản.


4

Tôi thích tính năng đổ lỗi trong GIT. Bạn có thể xem ai là tác giả của từng đoạn / dòng mã. Không chỉ là một tập tin.


Các VCS khác có cùng một điều (mặc dù thường không được gọi là "đổ lỗi").
Richard

Tôi sẽ -1 cái này vì nó là GIT cụ thể. OP không bao giờ đề cập đến GIT. Nhưng than ôi, tôi không có đủ đại diện để downvote.
Thomas Eding

2

Nếu bạn đang làm việc trên một dự án lớn có nhiều người đóng góp, chú thích mỗi tệp với danh sách các tác giả sẽ không hoạt động. Bạn làm gì với danh sách các tác giả khi bạn chia một tệp thành nhiều tệp nhỏ hơn? Bạn có giữ tên tác giả ban đầu nếu bạn viết lại mã hoàn toàn không? Bạn có thêm tên của bạn vào danh sách các tác giả khi bạn sửa một lỗi đánh máy trong bình luận không?

Những câu hỏi này là tốt hơn để lại cho hệ thống kiểm soát phiên bản.

Nhưng tôi không hoàn toàn chống lại danh sách các tác giả. Giữ một danh sách các tác giả cho toàn bộ dự án có ý nghĩa hoàn hảo. Nếu đó là một dự án tập tin duy nhất, chắc chắn, hãy giữ nó bên trong chính tập tin đó. Nếu dự án lớn hơn, hãy giữ nó trong README hoặc tệp nguồn cấp cao nhất của bạn (còn gọi là main.c). Nhưng đừng lặp lại chính mình bằng cách liệt kê các tác giả trong mỗi tệp.


1

Chúng tôi theo dõi bằng cách sử dụng hệ thống kiểm soát phiên bản hoặc bằng cách đặt @authormã. Một cách khác để làm điều đó là nói một cách tổng quát hơn, rằng một số người nhất định là tác giả cho toàn bộ mô-đun hoặc cho toàn bộ chương trình. Điều đó khuyến khích mọi người nghĩ về bản thân họ như là một phần của một nhóm thay vì là một bánh răng trong máy chịu trách nhiệm cho chính xác X số lượng chức năng hoặc dòng mã.


0

tôi sử dụng nhận xét kiểu Doxygen (hoặc đôi khi là KernelDoc) cho mọi thứ. Tôi chủ yếu làm việc trong C và PHP, nơi Doxygen khá phổ biến.

Trong hầu hết các trường hợp, ít nhất là hữu ích để bao gồm các thông tin sau:

  • Quyền (hoặc không) để sao chép nó / Bản quyền của công ty hoặc cá nhân
  • Tên tác giả / e-mail
  • Ngày viết
  • Ngày sửa đổi lần cuối

Điều đó sẽ giúp bất cứ ai tình cờ làm việc với tệp biết họ có gì, họ có thể làm gì với nó và họ có thể yêu cầu giúp đỡ nếu họ cần. Nó cũng cho họ biết nếu họ đang nhìn thứ gì đó 10 tuổi.


0

Cá nhân tôi không làm điều này bởi vì đó là tài liệu bổ sung như những người khác nói, nằm trong kiểm soát phiên bản. Nhưng nếu tôi định tạo ra một số đoạn mã kung-fu, có lẽ tôi sẽ thích hợp với bất cứ điều gì IDE của tôi có khả năng tự động tạo.

Chẳng hạn, sử dụng trong Delphi 7 với những CNTools hữu ích được cài đặt, tôi gõ

///a [enter]

và đi ra

//<author></author>

sau đó tôi gõ

///d [enter]

và đi ra

 //<date></date>

Tôi tưởng tượng rằng nó tương ứng với thứ gì đó mà một số tiện ích của bên thứ 3 có thể nhận được, nhưng đối với tôi - tôi đã có một tiêu chuẩn mà tôi thậm chí không phải tự trang điểm và làm hỏng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.