Cập nhật
Phản ứng của tôi trong trích dẫn để nhấn mạnh:
Tôi tin rằng câu trả lời nêu rõ các bình luận không nên được giải quyết trong Tiêu chuẩn mã hóa và sau đó liệt kê một bộ câu hỏi phòng thủ để chống lại nó, là câu trả lời đúng duy nhất.
Vấn đề ở đây là Tiêu chuẩn mã hóa chỉ là Tiêu chuẩn . Những ý tưởng cực kỳ chủ quan không nên có trong Tiêu chuẩn mã hóa . Nó có thể là một hướng dẫn trong Thực tiễn tốt nhất, nhưng hướng dẫn đó không thể được sử dụng để chống lại nhà phát triển trong quá trình Đánh giá mã. Theo ý kiến cá nhân của tôi, Tiêu chuẩn mã hóa phải càng gần với Tự động hóa càng tốt. Có quá nhiều thời gian lãng phí trong Đánh giá mã tranh luận về cách đặt tên, khoảng cách, tab, dấu ngoặc, nhận xét, v.v. khi TẤT CẢ nó có thể được tự động hóa. Ngay cả câu trả lời về tablesvà chairscó thể được tự động. LINT'ers cho phép từ điển, Kiểm tra viết hoa theo khái niệm (Biến, Hàm, Phương thức, Lớp, v.v.).
Ngay cả việc kiểm tra JavaDoc cũng có thể được Robot LINT'er triển khai trước khi Yêu cầu kéo được chấp nhận. Rất nhiều dự án nguồn mở thực hiện điều này chính xác. Bạn gửi Yêu cầu kéo của mình, mã được xây dựng với tệp Travis-CI, bao gồm Phân tích tĩnh và nó phải vượt qua tất cả các Tiêu chuẩn mã hóa có thể được thể hiện một cách khách quan. Không có tiếng chuông của con người trong việc 'làm điều đó không chính xác' hoặc không 'cung cấp giá trị' với một nhận xét, hoặc cách sai để đặt tên biến, et el. Những cuộc thảo luận đó không mang lại giá trị nào và tốt nhất là để lại cho một robot bên thứ ba có thể vượt qua sự mã hóa cảm xúc của chúng ta.
Để thực sự trả lời câu hỏi, chúng tôi sẽ phải giải quyết cách viết một Tiêu chuẩn nhằm giải quyết câu hỏi sau: Nhận xét này có cung cấp giá trị không? Tiêu chuẩn mã hóa có thể không thể ra lệnh 'giá trị' của một nhận xét. Do đó, nó trở nên cần thiết cho một người đi qua danh sách kiểm tra đó. Việc chỉ đề cập đến các bình luận trong Tiêu chuẩn mã hóa sẽ tạo ra một danh sách kiểm tra mà Poster gốc muốn tránh.
Đó là lý do tại sao các bình luận thường không được trình biên dịch xử lý và loại bỏ. Giá trị của chúng không thể được xác định. Là nhận xét trong câu hỏi có giá trị; có hay không?. Trả lời câu hỏi này là NP-hard. Chỉ có con người mới có cơ hội trả lời đúng, và thậm chí sau đó nó chỉ có thể được trả lời tại thời điểm nó được đọc, bởi người đang đọc nó; nơi giá trị của bình luận đó bị ảnh hưởng bởi thời tiết, cuộc sống gia đình của anh ấy hoặc cô ấy, cuộc họp cuối cùng họ chỉ tham dự và không kết thúc tốt đẹp, thời gian trong ngày, lượng cà phê họ đã uống. Tôi tin tưởng bức tranh đang trở nên rõ ràng hơn.
Làm thế nào nó có thể được thể hiện đúng trong bất kỳ Tiêu chuẩn nào? Một tiêu chuẩn không hữu ích trừ khi nó có thể được áp dụng một cách nhất quán và công bằng, trong đó công bằng hơn về tính khách quan chứ không phải tình cảm.
Tôi tranh luận rằng Tiêu chuẩn mã hóa phải duy trì mục tiêu nhất có thể. Các biến số được đặt tên là mục tiêu IS. Chúng có thể dễ dàng được kiểm tra đối với một từ điển để đánh vần đúng, cấu trúc ngữ pháp và vỏ. Bất cứ điều gì ngoài đó là một "trận đấu tức giận" được chiến thắng bởi người có sức mạnh nhất hoặc "đánh bại trán". Một cái gì đó, cá nhân tôi, đấu tranh với KHÔNG làm.
Khi tôi bình luận, tôi luôn bình luận nói chuyện với bản thân tương lai của tôi ở người thứ ba. Nếu tôi quay lại mã này sau 5 năm, tôi cần biết điều gì? Điều gì sẽ hữu ích, điều gì sẽ gây nhầm lẫn và điều gì sẽ lỗi thời với mã? Có một sự khác biệt giữa mã tài liệu để tạo API công khai có thể tìm kiếm và mã nhận xét cung cấp giá trị cho bên thứ ba không xác định, ngay cả khi bên thứ ba đó là chính bạn.
Đây là một bài kiểm tra litmus tốt. Nếu bạn là người duy nhất trong dự án. Bạn biết bạn là người duy nhất trong dự án. Điều gì sẽ có trong tiêu chuẩn mã hóa của bạn? Bạn muốn mã của mình sạch sẽ, tự giải thích và dễ hiểu cho chính mình trong tương lai. Bạn có muốn xem lại mã với chính mình về lý do tại sao bạn không đưa ra nhận xét trên mỗi dòng không? Bạn có xem lại từng bình luận bạn đã tạo trên 100 tệp bạn đã đăng ký không? Nếu không thì tại sao lại ép người khác?
Một điều tôi tin là đã bỏ lỡ trong các cuộc thảo luận này là Tương lai Bạn cũng là nhà phát triển cho dự án này. Khi hỏi về giá trị, ngày mai bạn cũng là một người có thể rút ra giá trị từ nhận xét. Vì vậy, quy mô đội, theo tôi không quan trọng. Kinh nghiệm nhóm không thành vấn đề, nó thay đổi quá thường xuyên.
Không có số lượng mã nhận xét nào xem xét điều này ngăn chặn một nhà sản xuất tốc độ khỏi bị rơi và giết chết một bệnh nhân. Khi bạn nói về một nhận xét ảnh hưởng đến mã, bây giờ bạn sẽ nói về mã không phải là nhận xét. Nếu tất cả chỉ là một bình luận bị thiếu để giết một ai đó, thì có một thứ khác có mùi trong quá trình này.
Giải pháp cho loại mã hóa nghiêm ngặt này đã được cung cấp như một phương pháp để tự viết phần mềm. Và nó không có gì để làm với ý kiến. Vấn đề với ý kiến là họ KHÔNG có tác động đến cách thức sản phẩm cuối cùng hoạt động. Những bình luận tốt nhất trên thế giới không thể ngăn phần mềm bị sập khi được nhúng trong bộ tạo tốc độ. Hoặc khi đo các tín hiệu điện bằng EKG di động.
Chúng tôi có hai loại ý kiến:
Máy có thể đọc bình luận
Các kiểu nhận xét như Javadoc, JSDoc, Doxygen, v.v ... là tất cả các cách nhận xét giao diện công cộng mà một bộ mã cung cấp. Giao diện đó chỉ có thể được sử dụng bởi một nhà phát triển khác (mã sở hữu cho nhóm hai người), một số nhà phát triển không xác định (ví dụ JMS) hoặc cho toàn bộ bộ phận. Mã này có thể được đọc bởi một quy trình tự động, sau đó tạo ra một cách khác để đọc các nhận xét đó, ala HTML, PDF, v.v.
Loại bình luận này là dễ dàng để tạo ra một tiêu chuẩn cho. Nó trở thành một quy trình khách quan để đảm bảo mọi phương thức, hàm, lớp có thể gọi công khai có thể chứa các bình luận cần thiết. Tiêu đề, tham số, mô tả et. el. Điều này là để đảm bảo rằng nhóm khác dễ dàng tìm và sử dụng mã.
Tôi đang làm một cái gì đó có vẻ điên rồ, nhưng nó thực sự không
Những bình luận này ở đây để giúp người khác thấy TẠI SAO mã này được viết theo một cách nhất định. Có lẽ có một lỗi số trong bộ xử lý mà mã đang chạy và nó luôn làm tròn, nhưng các nhà phát triển thường xử lý mã làm tròn. Vì vậy, chúng tôi nhận xét để đảm bảo rằng nhà phát triển chạm vào mã hiểu lý do tại sao bối cảnh hiện tại đang làm một cái gì đó thường có vẻ không hợp lý, nhưng thực tế đã được viết theo cách đó.
Loại mã này là nguyên nhân gây ra rất nhiều vấn đề. Nó thường không bị lỗi và sau đó được tìm thấy bởi một nhà phát triển mới và 'đã sửa.' Do đó phá vỡ mọi thứ. Ngay cả khi đó, các ý kiến chỉ ở đó để giải thích TẠI SAO không thực sự ngăn chặn bất cứ điều gì phá vỡ.
Nhận xét không thể dựa vào
Bình luận cuối cùng là vô dụng và không thể tin tưởng. Bình luận thường không thay đổi cách chạy chương trình. Và nếu họ làm như vậy, thì quá trình của bạn đang gây ra nhiều vấn đề hơn thì nó nên. Nhận xét là suy nghĩ và không bao giờ có thể là bất cứ điều gì nhưng. Mã là tất cả những gì quan trọng vì đó là tất cả những gì được xử lý bởi máy tính.
Điều này nghe có vẻ asinine, nhưng chịu đựng tôi. Cái nào trong hai dòng này thực sự quan trọng?
// We don't divide by 0 in order to stop crashes.
return 1 / n;
Trong ví dụ này, tất cả vấn đề là chúng tôi không biết 'n' là gì, không có bất kỳ kiểm tra nào cho 0 và ngay cả khi có, không có gì ngăn cản nhà phát triển đặt n = 0SAU kiểm tra cho 0. Do đó, nhận xét là vô dụng và không có gì tự động có thể bắt được điều này. Không có tiêu chuẩn có thể bắt được điều này. Các bình luận, trong khi khá (với một số) không có liên quan đến kết quả của sản phẩm.
Hướng phát triển thử nghiệm
Điều gì có kết quả trên sản phẩm? Các ngành công nghiệp trong đó mã được viết theo nghĩa đen có thể lưu hoặc giết một ai đó phải được kiểm tra nghiêm ngặt. Điều này được thực hiện thông qua đánh giá mã, đánh giá mã, thử nghiệm, thử nghiệm, đánh giá mã, thử nghiệm đơn vị, thử nghiệm tích hợp, thử nghiệm, dàn dựng, tháng thử nghiệm, đánh giá mã và thử nghiệm cá nhân, dàn dựng, đánh giá mã, thử nghiệm, và cuối cùng có thể đi vào sản xuất. Bình luận không có gì để làm với bất kỳ điều này.
Tôi thà mã không có bình luận, có thông số kỹ thuật, có các bài kiểm tra đơn vị xác minh thông số kỹ thuật, nghiên cứu về kết quả của việc chạy mã trên thiết bị sản xuất, sau đó là mã tài liệu chưa từng được kiểm tra, cũng không có gì để so sánh mã chống lại.
Tài liệu rất hay khi bạn cố gắng tìm hiểu TẠI SAO ai đó đã làm một điều gì đó theo một cách nhất định, tuy nhiên, tôi đã tìm thấy trong những năm qua rằng tài liệu thường được sử dụng để giải thích tại sao một cái gì đó 'thông minh' được thực hiện, khi nó thực sự không cần thiết được viết theo cách đó.
Phần kết luận
Nếu bạn làm việc tại một công ty YÊU CẦU mỗi dòng được nhận xét, tôi ĐẢM BẢO ít nhất hai trong số các kỹ sư phần mềm trong dự án đã viết một chương trình tài liệu tự động trong Perl, Lisp hoặc Python để xác định ý tưởng chung về những gì dòng đang làm , sau đó thêm một nhận xét trên dòng đó. Bởi vì điều này là có thể làm, nó có nghĩa là các ý kiến là vô ích. Tìm các kỹ sư đã viết các tập lệnh này để tự động ghi lại mã và sử dụng chúng làm bằng chứng cho lý do tại sao 'Nhận xét về mọi dòng' đang lãng phí thời gian, không cung cấp giá trị và có khả năng gây tổn thương.
Ở một bên, tôi đang giúp một người bạn thân với một bài tập lập trình. Giáo viên của ông đã đặt ra một yêu cầu rằng mọi dòng phải được ghi lại. Vì vậy, tôi có thể thấy quá trình suy nghĩ này sẽ đến từ đâu. Chỉ cần tự hỏi, bạn đang cố gắng làm gì, và đây có phải là điều đúng đắn? Rồi tự hỏi bản thân; Có cách nào để 'trò chơi' hệ thống với quy trình này không? Nếu có, thì nó thực sự bổ sung bất kỳ giá trị nào? Người ta không thể tự động viết các bài kiểm tra đơn vị kiểm tra mã nào đáp ứng một đặc điểm kỹ thuật nhất định và nếu có thể, đó sẽ không phải là điều xấu.
Nếu một thiết bị phải hoạt động trong một số điều kiện nhất định vì nó sẽ ở bên trong con người, cách duy nhất để đảm bảo thiết bị sẽ không giết chúng là nhiều năm thử nghiệm, đánh giá ngang hàng, thử nghiệm và sau đó KHÔNG BAO GIỜ thay đổi mã lần nữa. Đây là lý do tại sao NASA vẫn / vẫn đang sử dụng phần cứng và phần mềm cũ như vậy. Khi nói đến sự sống hay cái chết, bạn không chỉ 'tạo ra một chút thay đổi và kiểm tra nó.'
Bình luận không có gì để làm với cuộc sống. Nhận xét là dành cho con người, con người mắc lỗi, ngay cả khi viết bình luận. Đừng tin con người. Ergo, đừng tin vào những bình luận. Bình luận không phải là giải pháp của bạn.