Bạn có viết tiêu đề trong bình luận mã? [đóng cửa]


17

Tôi đã duyệt một số mã cũ mà tôi đã viết (năm đầu tiên ở trường đại học) và nhận thấy rằng tôi đã từng viết tiêu đề bình luận trước các phần khác nhau của mã. Những thứ như (đây là từ một trò chơi Monopoly):

/*Board initialization*/
...code...

/*Player initialization*/
...code...

/*Game logic starts here*/
/*Displaying current situation*/
...code...

/*Executing move*/
...code...

/*Handle special event*/
...code...

/*Commit changes, switch to next player*/
...code...

Điều này có thể là dư thừa và không cần thiết nếu mã thực sự rất rõ ràng, nhưng khi tôi quét qua tệp, nó làm tôi ngạc nhiên đến mức tôi cảm thấy như thế nào khi biết những gì đang diễn ra mặc dù tôi hầu như không nhìn vào mã thực tế. Tôi chắc chắn có thể thấy điều này là phù hợp trong một số trường hợp nhất định, vì vậy tôi tự hỏi - bạn có làm điều này không? Bạn có nghĩ rằng đó là một ý tưởng tốt? Hay là quá nhiều?

Câu trả lời:


24

Đây là một mùi mã. Điều này nói những gì và không tại sao .

Nếu điều này là cần thiết, chia mã trong các chức năng nhỏ.


4
Không có điểm nào có chức năng để có chức năng.
Paul Nathan

30
là đúng: nếu mã xứng đáng nhận xét như thế /*Board initialization*/, có lẽ nó phải ở trong một hàm được gọi InitializeBoard. Nếu cấu trúc mã của bạn đủ rõ ràng thì bạn sẽ không cần bình luận.
Tim Robinson

3
"Cái gì" là tốt để biết, và thường không rõ ràng khi nhìn vào mã. Những ý kiến ​​làm cho ý định tổng thể rõ ràng.
DarenW

4
@DarenW - nhưng các hàm / thủ tục / phương thức cũng vậy. Và sau này có thêm lợi ích của việc mô đun hóa mã, giúp dễ hiểu hơn .
Stephen C

3
Một lợi ích khác của điều này là các chức năng như InitializeBoardhoặc InitializePlayersẽ xuất hiện trong danh sách trình duyệt chức năng / mô-đun / lớp của hầu hết các IDE trong khi các bình luận thì không. Điều hướng dễ dàng hơn.
Steve Fallows

13

Tôi làm việc đó mọi lúc. Cả hai để đánh dấu những gì mã đang làm, và có lẽ quan trọng hơn, như bạn đã nói, để làm cho nó dễ dàng quét và tìm một đoạn mã. Đôi khi, tôi cũng sẽ viết ra một quy trình liên quan trong các bình luận và 'điền vào' mã dưới các bình luận khi tôi đi.


7
+1 - sự rõ ràng là một điều tốt. Tôi không đồng ý với câu trả lời được phê duyệt nói rằng đây là mùi mã. Nếu nó thêm rõ ràng - làm điều đó.
quick_now

2
Nếu nó vi phạm OAOO, thì đừng làm điều đó. Nó dư thừa và có xu hướng không đồng bộ với mã mà nó ghi lại. Đặt mã vào một hàm và đặt tên hàm với những gì nó làm. IDE hiện đại giúp dễ dàng thay đổi tên hàm và cập nhật tất cả các tham chiếu. Bằng cách đó, tất cả các trường hợp luôn cập nhật.
Scott Whitlock

3
+1 từ tôi. Trong các tệp mã lớn, tôi muốn có nhiều hơn chỉ là khoảng trắng phân tách các phần logic. Vâng, tôi nghĩ rằng nếu chức năng của bạn là loooooong thì bạn cần phải tách nó ra, nhưng tôi thấy nó dễ đọc hơn rất nhiều nếu các phần được phân tách bằng các bình luận.
Anthony

6

Tôi thấy thú vị khi nhiều người không thích thực hành mà không thực sự có thể nói rõ tại sao. Lý do những bình luận như thế được tán thành là chúng là một dấu hiệu bạn đã vi phạm nguyên tắc trách nhiệm duy nhất. Tên cụ thể đó thường chỉ được sử dụng trong ngữ cảnh OO, nhưng khái niệm chung cũng được gọi là sự gắn kết và áp dụng cho các mô hình khác. Các trường thường không dạy những loại nguyên tắc thiết kế đó cho đến khi kết thúc chương trình cấp bằng, nếu có. Trên thực tế, một số giáo viên bắt buộc vi phạm để làm cho mọi thứ dễ dàng hơn bằng cách nhồi nhét mọi thứ vào một tệp. Do đó, sự thiếu hiểu biết của sinh viên năm nhất của bạn là có thể tha thứ được, và thực tế bạn nhận thấy "có gì đó" sai và cố gắng làm rõ bằng các bình luận thậm chí còn được khen ngợi trong các tình huống, nhưng nói chung, tốt hơn là sửa một thiết kế không rõ ràng hơn là cố gắng viết lên nó bằng các bình luận.


4

Tôi xem những điều này như một cách để làm cho mã rõ ràng hơn hay không. Nếu bạn có thể nói dựa trên các phương thức trong tệp thì mỗi phần là gì thì không cần tuy nhiên nếu bạn phải có nhiều phần thì nó có thể hữu ích. Có lẽ khi một tệp mã quá lớn, nó cần được chia nhỏ, điều này có thể làm giảm nhu cầu bình luận như vậy.

Tôi sẽ nói nếu làm việc trong một nhóm để đưa ra một tiêu chuẩn để bạn ít nhất là mã hóa và nhận xét theo cùng một cách để việc nhìn vào mã trở nên dễ dàng hơn.


3

Tôi làm điều này bởi vì tôi thường truyền đạt ý định cho bản thân hoặc về cơ bản là đặt một dấu trang thuận tiện cho những việc như "Làm sạch dữ liệu bắt đầu từ đây". Thông thường dưới tiêu đề đó là một chút ngắn gọn về logic của những gì tôi đang làm và tại sao.

Tôi thích sự dư thừa. Nếu tôi mất sổ ghi chép trong phòng thí nghiệm của mình vì lý do này hay lý do khác hoặc phải xem lại mã tôi đã viết cách đây nhiều năm, tôi không thích phải ghép lại những gì tôi đang làm và tại sao tôi lại làm điều đó. Nếu ít nhất một số logic đó có trong mã, thì tài liệu đó đủ để tôi ít nhất làm việc với nó một lần nữa.

Tôi nghĩ rằng một phần thiên hướng của tôi đối với nó là một lượng lớn chương trình của tôi có tính chất thống kê, và do đó có phần lặp đi lặp lại. Trong khi có thể có một vài đoạn mã mà tôi có một hàm được đặt tên hữu ích để tìm kiếm, tôi có thể có hàng tá cách sử dụng tương tự như một hàm mô hình tuyến tính nói chung. Thật hữu ích khi có thể đi và tìm ra cái nào trong số đó là "mức độ nhạy cảm của kết quả đối với mã Lựa chọn A so với Lựa chọn B hoặc C" và đó là một thứ khác. Điều đó thường được tăng tốc bởi các tiêu đề.


Nhận xét nêu rõ mục đích kinh doanh / mục đích cấp cao là rất đáng giá. Họ cho phép xác nhận và hỗ trợ sự hiểu biết. Các bài kiểm tra đơn vị cũng có thể được cho là dư thừa - Tôi sẽ đề xuất rằng việc viết mã & hiểu mã ít nhất cũng quan trọng như kiểm tra nó.
Thomas W

2

Tôi nghĩ rằng nó hữu ích trong các tình huống khi bạn có các tệp nguồn khổng lồ với hàng tá chức năng và bạn có thể sắp xếp chúng thành các khối như thế. Tôi không nói rằng tôi thích điều đó tốt hơn các tệp nguồn nhỏ hơn, tập trung hơn tuy nhiên ...

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.