2010-09-16 3 views
11

Trong hầu hết các nhóm, có một quy tắc cho biết rằng các từ khóa @author và @since phải được sử dụng cho tất cả các lớp được tài liệu, đôi khi thậm chí là các phương pháp.Việc quản lý mã nguồn có làm cho @author của Javadoc và @since thừa không?

Trong nỗ lực tập trung vào những gì quan trọng, tôi không sử dụng các từ khóa này và thay vào đó dựa vào thực tế là tôi có thể sử dụng hệ thống quản lý kiểm soát nguồn để xác định ai là tác giả của lớp và kể từ khi nào nó tồn tại.

Tôi tin rằng @author và @since đến từ thời điểm kiểm soát phiên bản chưa phổ biến và tôi nghĩ rằng chúng khá dư thừa ngay bây giờ. Bạn nghĩ thế nào về cái này? Nên các dự án Java hiện đại sử dụng chúng?

Trả lời

17

Tôi nghĩ rằng thẻ @author thực sự gây nhầm lẫn mọi thứ. Trước hết, nếu nó không được cập nhật một cách khôn ngoan, nó sẽ trở thành sai. Ngoài ra, nếu bạn (không phải là tác giả gốc) thay đổi một nửa lớp học thì sao? Bạn có cập nhật @author không? Bạn có thêm một cái không? Và nếu bạn chỉ thay đổi một vài dòng trong lớp học thì sao?

Tôi cũng nghĩ rằng nó quảng bá quyền sở hữu mã, điều mà tôi không nghĩ là điều tốt. Mọi người nên được phép thay đổi một tập tin. Nếu có một thẻ @author, mọi người sẽ có xu hướng để tác giả này thực hiện tất cả các thay đổi thay vì tự thực hiện và có thể học được điều gì đó trong quá trình này.

Cuối cùng, như bạn đã nói, thông tin tương tự, chi tiết hơn, khả dụng từ VCS của bạn. Bất cứ điều gì bạn thêm vào trong Javadoc đều là trùng lặp. Và trùng lặp là xấu, phải không?

EDIT: Câu trả lời khác đề cập đến thực tế là bạn có thể không có quyền truy cập vào VCS và trong trường hợp này, thẻ @author hữu ích. Tôi khiêm nhường không đồng ý. Trong những trường hợp như vậy, bạn có nhiều khả năng giao dịch với thư viện của bên thứ 3 hoặc có thể là một tạo phẩm từ một nhóm khác trong công ty của bạn. Nếu đúng như vậy, liệu người đó có tạo ra một lớp học nào đó thực sự quan trọng không?Rất có thể, bạn chỉ cần biết thực thể đã tạo thư viện và nói chuyện với người liên hệ của họ.

+2

+1, tôi nghĩ rằng thẻ tác giả là vô ích. –

+0

Tôi không đồng ý với đánh giá thẻ @Author chút nào - +1 – aperkins

+0

Sao chép chỉ tốt cho dự phòng, như trong Mã sửa lỗi. – ninjalj

2

Tôi biết rằng chúng tôi đã sử dụng chúng và chúng thực sự tốt đẹp khi chỉ cần đọc mã nguồn. Tôi đã có nhiều hơn một tình huống mà @since đã thực sự tiện dụng để có trong đó, vì nó sẽ phải mất một chút công việc để xác định những gì phiên bản một cái gì đó đã được thêm vào (bằng cách so sánh ngày, vv).

Chỉ là trải nghiệm của tôi. Tôi nghĩ rằng các @author đã được ít hữu ích, nhưng kể từ khi chúng tôi có thể autogenerate cả hai phần dữ liệu khi tạo các lớp học mới, nó không có vẻ như một sự lãng phí để chỉ cho hệ thống làm điều đó với tôi.

1

Tôi nghĩ rằng các quy tắc tài liệu chỉ nên được thực thi nếu bạn cần chúng. Nếu bạn không cần phải đặt những thứ đó trong Java Documents, thì đừng thực thi quy tắc. Một trường hợp quan trọng là nếu có ai cần xem thông tin đó và không có quyền truy cập vào điều khiển phiên bản của bạn

4

Tốt cho một điều, khả năng hiển thị Javadoc thường vượt quá khả năng hiển thị kiểm soát nguồn. Tôi có thể xem Javadocs cho thư viện Java 1.1 nhưng không thể để kiến ​​thức của tôi tự do nghiên cứu lịch sử phiên bản của Sun từ lúc đó.

Bạn đang nói như thể Javadocs của bạn hoàn toàn bị cô lập với bạn (nhà phát triển) và không được phân phối cho những người khác như là một phần của API, v.v. Đó không phải lúc nào cũng như vậy. Thông thường các thông tin Javadocs và VCS phục vụ các mục đích hoàn toàn khác nhau.

Đối với tôi, ngay cả khi tôi có quyền truy cập miễn phí vào lịch sử phiên bản của tệp, tôi thích có thể nhìn thấy nó ngay tại nguồn, vì lý do tương tự mà tôi thích nhận xét giải thích mã lẻ trong tệp thay vì phải đi đến mô tả cam kết cho một khối mã nhất định. Nhanh hơn.

+0

Một số hệ thống kiểm soát phiên bản thậm chí còn hỗ trợ điền thông tin tác giả và các nội dung tương tự để bạn thực sự có thể hưởng lợi từ các trường hợp sử dụng như thế này mà không cần cung cấp thông tin dư thừa. Điều này thường phải được kích hoạt một cách rõ ràng để ngăn chặn sự tham nhũng của các tập tin mà các đánh dấu từ khóa không có nghĩa là để được thay thế. Đây là cách nó hoạt động trong Subversion, ví dụ. http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html – Archimedix

+0

@Archimedix: Tôi thấy rằng đó là một túi hỗn hợp. Tôi thường thích tác giả tĩnh hơn. Nếu không, bạn sẽ gặp phải tình huống mà ai đó vừa sửa lỗi đánh máy trên tệp và bây giờ họ là "tác giả" của tệp. Công ty chúng tôi tự động giải quyết nó và tôi thấy nó ít hữu ích hơn. Tôi đồng ý với jqno khi nghĩ rằng thẻ @author không tự cung cấp toàn bộ lợi ích. –

+0

Vâng, đây thực sự là một vấn đề ... tuy nhiên, tôi không thể nghĩ ra cách nào khác để giải quyết vấn đề này một cách thỏa đáng ... đối với các tệp không phải nhị phân, người ta có thể nghĩ đến từ khóa tác giả mở rộng hoặc phiên bản được tham số hóa liệt kê các tác giả có liên quan nhất theo đóng góp của họ bắt nguồn từ một hoạt động đổ lỗi cho VCS (thường rất tốn kém và do đó không thực sự hữu ích cho mục đích đó trong thực tế). Vì vậy, có vẻ như cách duy nhất để làm cho nó được thực hiện đúng là để làm điều đó chính mình! ;-) – Archimedix

2

Không. Khán giả của các trang javadoc có thể không có quyền truy cập vào điều khiển nguồn của bạn, vì vậy thông tin này có liên quan.

@since quan trọng vì tài liệu có thể được tư vấn cho các phiên bản phần mềm cũ hơn. Khi bạn có thể nhìn thấy khi một tính năng được giới thiệu bạn biết 1) rằng nó không có sẵn cho bạn và 2) rằng có một lý do chính đáng để nâng cấp.

Tuy nhiên, bạn có thể sử dụng địa chỉ email để tác giả liên hệ với nhóm của bạn cho thẻ @author.

+0

Đồng ý với tính hữu dụng của '@ since', nhưng vâng ... ai quan tâm những gì cá nhân đã viết một lớp cụ thể hoặc phương pháp? – Svish