Comment khi code

![Comment khi code quyết định kỹ năng lập trình viên](//media.thanhnt.com/2016/02/comment-good-or-bad-developer.png

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 độ:

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.

//Chia đôi toàn bộ các phần tử của mảng đưa vào
public int[] half(int[] y){
  int[] x; //Tạo một array mới chứa kết quả
  for (int i = 0; i < y.length ; i++)  //Duyệt các phần tử của mảng y
  {
     x[i] = y[i]/2;  //Gán trá trị vào array chứa kết quả
  };
  return x; //Trả kết quả ra
}

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:

// 02/03/1992 Sửa tên class.

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:

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ì.

public object DoThing(){
  //Lấy 1 phần tử random từ database
  //Một đống code phức tạp
  return obj;
}

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

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:

//Chỉ cần nhìn tên hàm là biết hàm làm gì
public object GetRandomObjectFromDatabase(){
  return randomObj;
}

public int[] HalfAllNumbersFromInput(int[] input){
   int[] output; //Nhìn tên biến là biết biến làm gì
   for (int i = 0; i < input.length ; i++)
   {
      output[i] = input[i]/2;
      //Viết để dubug, sau này phải remove
      //Đây là comment bắt buộc phải viết, để giải thích lý do ta viết code
      Console.Write("Call this");
   };
   return output;
}

Ở đâ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.