Lang thang trên internet thấy cuốn sách “Code dạo ký sự” của Phạm Huy Hoàng hay hay, vui vui và cũng có chia sẻ nhiều kinh nghiệm trong nghề lập trình nên copy một đoạn trong sách này để các bạn đọc cho vui. (Phần này tác giả chia sẻ vài trang trong sách)
Link: http://book.toidicodedao.com
(PS: có bonus thêm 2 cuốn ebook mà tác giả có đề cập trong sách là: "
Clean Code" và "
Code Complete 2nd Edition")
-----------------------------------------------------------------------------------
LUẬN VỀ COMMENT CODE (PHONG CÁCH KIẾM HIỆP)
Comment code luôn là vấn đề gây tranh cãi sứt đầu mẻ trán trong giới võ lâm. Xưa kia, thuở còn mài đít trên ghê nhà trường, ta thường được các thầy dặn rằng: Code nhớ phải comment. Thuở mới đi làm, sơ nhập giang hồ, mỗi khi đọc code không hiểu, ta cũng hay đập bàn mà chửi: “Thằng này code ngu quá đ*o comment gì cả”.
Thế nhưng, lưu lạc giang hồ bao năm, đọc code cũng nhiều; từ code không comment cho tới code comment đầy đủ và sạch sẽ; ta vẫn băn khoăn không biết thật sự phải comment thế nào mới đúng. Thế rồi, sau khi đọc Clean Code, ta như lượm được bí tịch võ công trong truyền thuyết.
Ta ngộ ra được cái gọi là “đạo code”, “đạo comment”, đặt một bước chân vào con đường võ đạo đỉnh cao (Đạo ở đây là đạo lý, ko phải đạo nhạc như Sơn Tùng, các đạo hữu đừng hiểu lầm).
Lấy chuyện kiếm hiệp nói chuyện code
Thần Điêu Đại Hiệp của Kim Dung có đoạn: Dương Quá bị lạc vào kiếm mộ của Độc Cô Cầu Bại. Thuở còn sống, Độc Cô cầu bại là người kiếm thuật vô song, danh chấn thiên hạ. Trước khi chết, ông chôn 4 thanh kiếm ở nơi gọi là kiếm mộ.
Tại hạ muốn quý vị chú ý chi tiết này:
Một hồi sau, chàng mới đặt thanh kiếm nặng đó xuống, nhấc thanh kiếm thứ ba lên, lần này chàng lại bị lầm. Chàng cứ tưởng thanh kiếm này phải nặng hơn thanh kiếm vừa rồi, nên vận lực ra cánh tay. Nào ngờ nó nhẹ tênh như không, chàng ngưng thần xem kỹ, hóa ra đó là một thanh kiếm gỗ, chôn dưới đá lâu năm, thân và cán kiếm đều đã bị mục, đọc dưới mặt đá có khắc dòng chữ:
Sau bốn mươi tuổi, không mang binh khí.
Thảo mộc trúc thạch đều có thể dùng làm kiếm.
Cứ thế tinh tu, đạt tới cảnh giới vô kiếm thắng hữu kiếm.
Tổng kết lại, cuộc đời tu kiếm của Độc Cô Cầu Bại bao gồm ba giai đoạn:
- ∞ Lúc trai trẻ, lòng đầy nhiệt huyết mà thiếu sự chín chắn thì sử dụng tử vi kiếm là thanh bảo kiếm sắc, nhẹ và linh hoạt.
- ∞ Khi đạt độ chín của suy nghĩ và sức lực, sử dụng thanh kiếm sắt nặng nề mà không sắc bén.
- ∞ Khi bắt đầu về già, suy nghĩ và kiếm thuật đạt trình độ cao, vũ khí chỉ còn là thanh kiếm gỗ và đạt mức thượng thừa thì không kiếm mà thắng đối thủ, bất cứ thứ gì cũng là kiếm.
Ta tự thấy hầu như lập trình viên nào cũng sẽ phải trải qua ba giai đoạn này trên con đường “cầu đạo”. Kẻ nào ngộ tính cao thì chỉ cần làm việc một hai năm đã đạt tới cảnh giới cuối. Kẻ nào đầu óc u mê lạc lối thì cả đời vẫn cứ ở giai đoạn hai mà thôi.
Giai đoạn trẻ trâu đầy nhiệt huyết (Code không comment hoặc comment lung tung)
Kẻ nào sơ nhập giang hồ đều trải qua giai đoạn này. Đây là khi ta còn ngồi trên ghế nhà trường hoặc vừa 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 cũng 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, như thể mấy kẻ mới học võ công mà bày trò múa máy bắt chước các chiêu thức cao siêu trong võ học.
//Chia đôi toàn bộ các phần tử của mảng đưa vào public int[] half(int[] y){
//Tạo một array mới chứa kết quả
int[] x;
//Duyệt các phần tử của mảng y
for (int i = 0; i < y.length ; i++)
{
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 đoạn code trên 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 một số code không dùng nữa. Một số lỗi khác mà các đạo hữu này hay mắc phải như:
- ∞ Comment lại code cũ để “đề phòng”. Code không dùng nữa thì xóa đi, đừng comment. Có SVN rồi thì khi cần code cũ chỉ việc restore lại là xong.
- ∞ Comment để làm log. Đừ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 lập trình viên sẽ đạt đến giai đoạn này. Ở giai đoạn này, ta đã cảm thụ được một chân lý võ học : Comment 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ì:
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 xưa đã 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ì. Ngộ ra được điều này, các đạo hữu sẽ đạt tới cảnh giới cuối cùng trong “code học”.
Cảnh giới vô kiếm thắng hữu kiếm (Vô comment thắng hữu comment)
Đây là cảnh giới mà ta hy vọng các đạo hữu có thể đạt được. Ở cảnh giới này, ta code không cần comment nhiều. Giống như Độc Cô Cầu Bại có thể lấy kiếm gỗ làm kiếm, lấy lá cỏ làm kiếm, lấy tay làm kiếm; 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 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).
---------------------------------------------------------------------------------------------------------------------------------------------------
Ebook:
Link ebook:
http://www.mediafire.com/file/4s6ex96188...dition.pdf
Link ebook:
http://www.mediafire.com/file/ks9cg7bqnf...Martin.pdf