Page 49 - Ký sự code dạo

LẬP TRÌNH VIÊN ĐÂU PHẢI CHỈ BIẾT CODE

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 phải là why chứ không phải what. Ta viết comment để
người khác (hoặc chính 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.

// 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 bằng hữu
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à cảnh giới tối cao của “code
đạo”. Đừng học đòi theo lũ trẻ trâu mà viết code kiểu “càng ngắn càng
tốt”, càng khó hiểu càng tốt, đó chỉ là cái dũng của kẻ thất phu mà thôi.
Chúc các bằng hữu sớm thành cao thủ trên con đường cầu đạo, nhầm,
cầu code của mình.
Tóm tắt

• Đừng nghĩ rằng comment càng nhiều càng tốt, mà hãy viết code
sao cho dễ đọc, dễ hiểu, không cần comment.
• Comment nên là what (nói code làm gì) mà nên là why (Giải
thích tại sao lại phải thiết kế, viết code như vậy).

47