Tâm sự về Comment Code
Hôm nay được buổi làm bài test vô thưởng vô phạt, trắc nghiệm C++, 20 đoạn chương trình và yêu cầu compiler bằng…não. Dù có những đoạn ngắn ngủi chỉ 4 5 dòng code, nhưng thực sự mình không thể hình dung ra nổi kết quả sẽ là gì. Code được optimize rất cẩn thận, và như hack não vậy, alien language đúng nghĩa. Ôi tôi ước có comment ở đây…
Nhớ hồi mới học code, mình hay trao đổi bài tập nọ với nhóm, tuyệt nhiên cả chục dòng code không lấy đến 1 dòng comment chú thích nào, đọc code nhau rồi gãi đầu cái function kia để làm gì, ô dòng kia có chức năng thế nào vậy… cả buổi ngồi giải thích hết luôn thời gian thảo luận. Thi thoảng có thằng cùng lớp hỏi mày ơi làm cho tao bài này, mình làm rồi gửi mã nguồn cho nó, nó khóc, rep lại chả hiểu gì, lúc sau gửi lại cho mình code của nó, mình cũng khóc, chả hiểu nó viết gì. Lên daynhauhoc.com cũng vậy, topic kiểu như “ai đấy giúp em bài này với” rồi sau đó là cả đoạn dài lượt thượt, tên hàm tên biến đặt a b c rất khó hình dung, và cũng không lấy đến một dòng giải thích yêu cầu là gì, ý tưởng là gì, triển khai ra sao… và mình lại khóc, nước mắt lăn dài trên gương mặt thanh tú. (TnBS).
Quay lại với 20 câu trắc nghiệm, nó cho mình thấy rằng còn quá nhiều thứ phải học để có thể code được những dòng thần thánh như vầy, và ý thức được việc code sạch đẹp để dù phức tạp nhưng đến bà nội đọc cũng hiểu.
// Ngày xưa, khi tôi viết đoạn code này, chỉ có Chúa và tôi hiểu
// Bây giờ nhìn lại, chỉ có Chúa mới hiểu
Còn anh em? Anh em có comment cho những dòng code thần thánh của mình không?
[image] 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 c…
Từ coder đến developer - Tôi đi code dạo – 30 Mar 16
[Giải trí] Tổng hợp các comment “bá đạo” từ trước đến nay
Dạo gần đây viết nhiều bài về technical khá mệt và nhức đầu, lâu lâu mình viết một bài theo dạng “dịch và sưu tầm” để giải trí cho các bạn đọc vậy. Trước đây, mình từng có một bài viết …
Nên có luật phát thẻ những ai post code không giải thích
Trong này thì tùy tâm thôi
Mình thì khi nào thấy code không thể tự giải thích cho nó (self-document), hoặc nó quá tricky, đểu đểu, không mainstream lắm thì mình comment còn bình thường thì tập trung đặt trên biến tên hàm, viết hàm cho ngắn gọn thôi
Tôi thấy comment là phí thời gian tập trung và nếu giải quyết được rồi thì chẳng có cái động lực nào có thể biểu tôi quay lại đó comment cả.
Mình thì thấy nhiều trường hợp phải comment, ví dụ một số:
Mô tả file, thường đặt đầu dòng, mô tả tên file, ngày tạo, tên tác giả, bản quyền, các interface, các class, function có trong file. Thường IDE tự sinh ra cho mình, nhưng dùng Text Editor phải tự gõ tay.
Kế thừa từ thư viên ngoài, nhưng thư viện không viết theo convention, document đầy đủ, như mã ID toàn chữ sô, phải comment định dạng cho nó: computer id - app id - current date.
Viết mã giả, ban đầu viết mã giả bằng comment, sau đó viết code, mã giả hay comment là 1 bản detail design. Trong file có 2 góc nhìn, high level là comment, low level là code.
Giải thuật phức tạp, viết comment trên hàm của giải thuật, mô tả khái quát cách giải thuật hoạt động.
Comment sinh ra document như Javadoc.
Còn nữa mà mình chỉ biết nhiêu đó.
Một project có thể trải qua nhiều “đời” nhân viên, bạn không comment, sau này bạn nghỉ việc và nhân viên mới nhìn vào sẽ không hiểu bạn code gì…
Lập trình viên tốt = Tầm + Tâm
Mình cũng đau đầu về việc bàn giao project còn thay đổi chổ làm thì chắc không xảy ra vì mình là viên chức nhà nước. Mình đang làm theo hướng báo cáo kỹ thuật và open source. Không cần comment nhưng ltv sẽ báo cáo tất cả những thống kê kỹ thuật về project huy vọng như vậy sẽ tốt hơn trong tương lai. Còn hiệu quả hay không thì mình phải đợi, có điều anh em phải chịu khó thôi. Mình đang làm trước nhưng không biết các anh em còn lại có phục và làm theo không mới biết hiệu quả.
Cái tâm bạn chỉ nhìn tới được từng hàm thôi thì nó giới hạn cái tầm lại nhiều lắm. Các bạn làm việc tại những công ty lớn lương cao nên bạn có nhiều thời gian và tiền bạc cho đầu tư vào từng xử lý. Còn anh em tôi làm nhà nước thường ngày phải làm hơn 8h kể cả về nhà, t7, cn… công việc là 1 thằng từ a đến z trách nhiệm thì ghánh mà thân phận thì không. Cuối tháng các bạn có lương tụi tôi chỉ có lươn. Các bạn có quy trình làm việc chuyên nghiệp còn tụi tui phải tự lo lấy. Nếu dành thời gian comment tốt từng view thôi thì thời gian của chúng tôi nó đội lên cả đống rồi. Nên theo tôi chỉ cần bố cục không cần chi tiết. Còn ai có quan điểm khác là do môi trường làm việc của quyết định thôi.
Chia sẻ của bạn cũng hay, quả thật comment xử lý trước khi code sẽ nhẹ nhàng nhưng không nâng được nghĩ sâu, nhớ nhiều những tư duy tích cực và quan trọng trong lập trình. Qua vài lần code chắc không ai rảnh comment đâu vì nó quá dễ xơi rồi. Nên mình khẳng định comment code là không cần thiết.
Đúng rồi bạn. Có nguyên cả một tâp quy tắc viết clean code, viết ra code mà người khác đọc được. Vì vậy tiêu chí không có comment là 1 tiêu chí tốt, vì nó khiến cho lập trình viên phải chú trọng đến chất lượng code mà bản thân viết ra.
Tuy nhiên, mục tiêu là clean code nhưng không thể đạt tới mức “pure clean code” được, nghĩa là trong 1 app không có bất kì dòng comment nào. Luôn có 1 phần ngoại lệ, mình ước tính khoảng 10%, là có comment, nó rơi vào các trường hợp bất khả kháng. Mình chỉ liệt kê những trường hợp hiếm nên có comment để lập trình viên khác đọc code hiểu được.
Tiêu chí chung vẫn là viết clean code, comment chỉ chiếm 10%, và cố gắng refactor sao cho nó về 0%.
Cảm ơn chia sẻ của bạn, đọc comment của bạn mình thấy nhẹ nhàng và thoải mái lắm, có thêm kinh nghiệm bổ sung thêm vào quy trình làm việc của mình. Nhưng quả thật trong nhiều môi trường làm việc vì rất nhiều lý do người ta không thể đưa tiêu chí này vào (nhân lực thay đổi thường xuyên, chất lượng code các thành viên không đồng đều, bảo mật quy trình làm việc, tốn thời gian đào tạo cho nhân viên mới, đơn vị sử dụng nhiều mã nguồn… và vô số lý do khác). Nên vẫn còn những quan điểm khác đi và vẫn còn tranh luận trong tương lai.
Tùy mục đích và tùy chú viết là gì, viêt cái common để dùng chung thì nên viết rõ ràng, đăc biệt là cái comment đầu hàm trong Java là Java doc, Code mà người ta biết dùng nó mà không cần vào đọc source nó.
chú nhìn cái class String Java dưới mà xem, comment chắc gấp 2 code.
http://www.docjar.com/html/api/java/lang/String.java.html
Thường mình làm chú tâm cái javadoc trước. Còn comment hàm thì tùy xử lý, nếu bản thân nội dung đơn giản hoặc đọc vào biết ngay thì khỏi comment.
Cơ mà đọc code nguời khác vân thích đọc comment hơn :p. đỡ suy nghỉ.
code gì chục dòng không comment đã kêu. nếu như code cứ chục dòng lại comment thì thì phải xem xét lại người code. comment quá nhiều thường chứng tỏ người code bậy bạ, logic kém, không biết đặt tên hàm tên biến.comment chỉ dùng cho một số trường hợp cụ thể không thể giải thích bằng code. comment thường giải thích vấn đề why, không phải what .