Comment khi code – Dễ mà không dễ

Comment khi code quyết định kỹ năng lập trình viên

Mở đầu

Comment khi code luôn là vấn đề khá đau đầu, gây tranh cãi khắp mọi nơi. Khi còn mài mông trên ghế giảng đường, các thầy yêu cầu “Khi code nhớ phải comment” nhưng lại không nói thế nào mới là comment đúng chuẩn, đúng kiểu. Cho đến khi đi làm, khi đọc code của người khác viết mà không hiểu thì ta lại đập bàn mà chửi: “Thằng này code ngu như cờ hó, code không comment thì thằng nào đọc cho nổi?!?”.

Sau này đọc nhiều, đủ các thể loại code, từ code của bro đến newbie, từ code sạch cho đến comment đầy đủ ta vẫn không biết comment thế nào mới là đúng. Tôi có đọc code của windows 3.1 của mấy lão MS, thấy nhiều chỗ vui đáo để.

Có một cuốn sách nói khá kỹ về vấn nạn này được các tiền bối chỉ cho đó là cuốn Clean Code”. Các bạn có thể tải về ở đường link cuối bài viết.

Sách hoàn toàn bằng tiếng Anh, các bạn có thể sử dụng để học tiếng Anh và lấy kiến thức luôn một thể giống tôi. ^^

Trong một bài viết mà tôi đọc được thì người ta chia ra làm 3 cấp độ:

  • Trẻ trâu đầy nhiệt huyết (Comment càng nhiều càng ít).
  • Tạm chín chắn (Có chủ đề hơn).
  • Không comment mà như comment.

Giai đoạn trẻ trâu đầy nhiệt huyết
(Code không comment hoặc comment lung tung)

Đây là khi ta còn ngồi trên ghế nhà trường, hoặc mới đi làm. Code chạy được là mừng, đôi khi code cho xong là nộp, chả cần comment. Nhiều khi ta nghe lời các sư phụ, thêm comment vào code. Đống comment này nhiều nhưng khá vô dụng, đọc rất buồn cười. Comment mà như không.

Ta thấy code tuy comment khá đầy đủ, nhưng chẳng có ý nghĩa mấy, thời gian viết comment còn nhiều hơn viết code.

Một số coder thường dùng trò: Thêm comment để biết ngày giờ sửa code, comment lại 1 số code không dùng nữa.

Xin lỗi, code không dùng nữa thì xóa đi, đừng comment. Có SVN rồi khi cần code cũ chỉ việc restore lại là xong.
Đừng comment theo kiểu:

Sử dụng SVN có thể tra ra log rõ ràng và tiện dụng hơn nhiều.

Giai đoạn tạm chín chắn trong suy nghĩ (Biết cách comment)

Code một thời gian, hầu như mọi LTV sẽ đạt đến giai đoạn này. Ở giai đoạn này:

  • Comment khi code nên là what, không phải how.
  • Comment để nói code làm gì, không phải để giải thích việc code làm.

Lúc này, lập trình viên đã hiểu rõ hơn về cách comment. Với những đoạn code phức tạp, dài dòng, 1 dòng comment ngắn gọn sẽ giúp người sau dễ dàng hiểu đoạn code làm gì.

Tuy vậy, các bậc cao nhân đã rút ra được một điều:

  • Comment là thứ dối trá.
  • Khi sửa code, comment thường không được sửa, sẽ dẫn tới tình trạng: code một đằng, comment một nẻo.
  • Ta phải đọc cả code lẫn comment để biết code làm gì, phí gấp đôi thời gian.
  • Cách comment tốt nhất chính là dùng code, chính code sẽ nói code làm gì.

Cảnh giới không comment mà như comment

Ở cảnh giới này, ta code không cần comment nhiều. Ta thấy bất cứ thứ gì cũng có thể làm comment: tên biến cũng là comment, tên hàm cũng là comment, tên database cũng là comment. Code cũng như comment, comment cũng như code, code và comment tuy hai mà một.

Tuy nhiên, đôi khi bắt buộc phải dùng comment:

  • Khi viết JavaDoc, API v…v, ta bắt buộc phải comment và document, vì người dùng API chỉ được đọc document chứ không đọc code.
  • Một số trường hợp khác: comment là why chứ không phải what. Ta viết comment để người khác (hoặc ta sau này) biết vì sao ta lại viết code như vậy.
  • Comment có tác dụng nói những điều bản thân code không nói được.
  • Còn việc code làm gì, chạy như thế nào, chỉ cần đọc code là hiểu.
Ở đây, ta không phủ nhận độ hữu dụng của comment.

Nhưng vấn đề là: Nhiều gã coder lợi dụng comment để viết code không rõ ràng, khó hiểu, sau đó sử dụng comment để lấp liếm.

Điều ta muốn các LTV hiểu là: Hãy có gắng viết code một có rõ ràng nhất có thể, bằng cách đặt tên biến, tên hàm, tách code, … Đó mới là code sạch.

Tải về EBOOK

Ebook Clean Code

Khi nhìn vào một đoạn code, người ta có thể đánh giá một lập trình viên.

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz