Comment Code - Tại sao chúng ta nên Comment Code? (p1)
Comment code là một trong những chủ đề được tranh luận rộng rãi trong thế giới lập trình. Đó là điều mình được học ngay từ khi học môn đầu tiên về lập trình. Điều này dẫn đến có nhiều cuộc thảo luận “Chúng ta có nên comment code?”. Sự phong phú các của các câu bình luận chắc chắn đủ để khêu gợi quan tâm của mọi người. Theo các cuộc thảo luận, có người cho rằng comment là không cần thiết người thì nói có, trong khi một số khác thảo luận comment bao nhiêu là đủ và tại sao. Câu trả lời cho câu hỏi này là YES, chúng ta nên comment code của mình và bài viết này sẽ giải thích vì sao.
Đầu tiên, chúng ta hãy bắt đầu với lý do tại sao điều này đã trở thành một chủ đề trong thế giới máy tính.
Sự tiến bộ của phương pháp lập trình máy tính, các trình biên dịch, và ngôn ngữ cấp cao, đã đưa câu hỏi cơ bản này trở thành chủ đề gây nhiều sự quan tâm. Bây giờ chúng ta có thể sử dụng ngôn ngữ mang hướng tự nhiên như C, C ++, C++++, Java, Python, Ruby hay Perl….để viết chương trình do con người có thể hiểu được một đoạn tiếng Anh nhanh hơn nhiều so với có thể hiểu được một đoạn code với nghĩa tương tự. Những quan niệm sai lầm xảy ra khi chúng tôi bắt đầu nghĩ rằng có thể code những đoạn code đủ để hiểu được và không cần comment cho chúng.
Để hiểu lý do tại sao chúng ta nên comment, trước tiên chúng ta cần phải hiểu rõ mục đích của comment. Chúng ta cần comment để cho mọi người biết lý do tại sao code đó hoạt động. Phải thừa nhận rằng, lý do mình viết bài viết này là do code của mình bị chê là comment cũng như không comment, thật ra trước kia mình coding không hề comment nhưng từ khi đưa vài project lên github thì cũng ráng comment cho bằng chị bằng em nhưng chẳng đâu vào đâu. Dưới đây là một đoạn code với không có comment nào :
r = n / 2;
while (abs (r - (n / r))> t) {
r = 0,5 * (r + (n / r));
}
System.out.println ("r =" + r) ;
Không ai biết nó làm cái gì đúng không. Hãy thêm một comment.
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );
Như vậy sẽ khiến cho đoạn code dễ hiểu hơn.
Tại sao chúng ta phải viết các comment, nếu code của chúng viết gọn gàng và dễ hiểu?
Tại sao chúng ta cần phải giải thích cho các lớp và chức năng nếu code của chúng ta “rõ ràng” và dễ hiểu.Theo mình, chúng ta comment để nắm ý nghĩa của đoạn code đó. Comment là cách duy nhất để nắm bắt được ý nghĩa của code tại thời điểm viết đoạn code đó. Comment vào một code cho phép bạn hiểu được ý nghĩa của đoạn code đó vào thời điểm khi đoạn code đó được viết, vì khi bạn đọc cùng một đoạn code vào thời điểm khác có thể ý nghĩa của nó sẽ rất khác so với mục đích ban đầu của code tại thời điểm ban đầu của nó. Nếu bạn không comment điều này sẽ xảy ra:
Khi bạn đang viết một chương trình, tất cả mọi thứ về chương trình (ví dụ, các biến, cấu trúc chương trình, phân nhánh, vv) là đơn giản trong suy nghĩ của bạn và nó dễ nhớ. Nhưng điều gì sẽ xảy ra nếu bạn ngừng làm việc với các chương trình trong một năm, và sau đó quyết định bắt đầu làm việc lại với nó một lần nữa? Tất cả hoặc hầu hết các kiến thức trước đây của bạn về chương trình này sẽ không còn nhiều hoặc mất hết, và bạn sẽ phải bỏ ra một thời gian (hoặc rất nhiều thời gian, tùy thuộc vào chương trình) để tìm hiểu làm thế nào các chương trình hoạt động trở lại. Đây chỉ là một ví dụ giả thuyết, vấn đề này là một mối quan tâm thực sự cho rất nhiều người đã có nhiều dự án phải cập nhật sau một thời gian dài.
Khi nhìn vào bất kỳ đoạn code nào đó có thể sẽ là một chút đáng sợ cho người mới bắt đầu, nhưng nếu có comment trong các mã nó làm cho nó một chút dễ dàng hơn. Sử dụng comment trong đoạn code của bạn không chỉ hữu ích cho những người khác đang nhìn vào nó, nhưng nó cũng có thể hữu ích cho bạn. Nếu bạn có hàng trăm dòng code và đang cố gắng xem qua lại tất cả để chỉnh sửa hoặc thay đổi, nó sẽ dễ dàng hơn để tìm thấy phần nào đó quan trọng nếu bạn đã đặt comment trên doạn code đó. Các comment cũng có thể được sử dụng để theo dõi các thông tin, chẳng hạn như các tác giả, ngày code được tạo ra, và ngày code được cập nhật cuối cùng. Đây là tất cả các thông tin mà bạn muốn xuất hiện trong các document, nhưng không muốn hiển thị trên ứng dụng hoặc trang web của mình.
Do bài viết cũng khá dài nên mình chia làm 2 phần, phần 2 sẽ được đăng lên sớm nhất có thể.
Hê hê có người dịch Code Complete cho đọc rồi Có mấy cái range comic max hài
Nếu anh thích căn giữa ảnh cho cân thì có thể chèn kiểu này:
đỉnh cao của việc comment là không comment tí nào. Đặt tên biến ngắn gọn nhưng đủ nghĩa sẽ làm code dễ đọc hơn. Điều khó khăn là làm sao nghĩ được 1 cái tên biến như thế.
điều này sẽ được nói trong các bài viết sau, bạn cố chờ nhé
có tấm đăng hoài vậy anh
Đúng thế, comment có cái lợi là dễ hiểu cho người đọc, có cái hại là phải maintain comment nếu thay đổi logic.
Nên viết tên hàm dễ hiểu, xúc tích là tốt nhất.
nếu thay đổi logic thì mình thay đổi cả comment và giữ lại comment cũ gần đây nhất, còn thêm cả ngày và người thay đổi comment nữa cơ
Cái này ngày trước các dự án Nhật hay áp dụng thêm ngày vào dòng comment. Ở mức lý tưởng là comment nào cũng dễ hiểu thì con đọc được. Mục đích thêm comment là để maintain cho dễ, đa phần là mình sẽ đọc code của người khác nên nếu comment nhiều, change nhiều history thì nhìn thấy hàm toàn comment, chả có code mấy.
Comment cũng mất tác dụng lưu trữ khi thay đổi business của 1 đoạn code, có nghĩa là ta phải xóa hẳn đi và thay bằng đoạn mới, lúc này nội dung sẽ khác phải có comment khác.
Hoặc là trường hợp thêm 1 đoạn code mới vào code có sẵn, comment theo phong cách của ông này khác phong cách của ông kia => tại sao best practice cho code bjo là hạn chế comment thay vì thế expose nó ra hàm và đặt tên hàm đúng ý nghĩa.
Trong cuốn Code Complete có phần effectively comment nói về cách tối giản comment, đặt bên hàm, sử dụng các biến… mình sẽ viết phần này vào cuối chuỗi bài này.