Với những ai đã từng viết code, ngoài việc đảm bảo output đúng, chúng ta cũng thường đặt câu hỏi: “viết code thế này đã chuẩn chưa?”

Hầu hết mọi người, nhất là những bạn còn đi học hoặc chưa có nhiều kinh nghiệm, đều nhiều lần tặc lưỡi nghĩ rằng “code chạy đã, đẹp xấu tính sau”. Chính suy nghĩ này dẫn tới việc ngay bản thân họ, một thời gian sau cũng không còn hiểu được họ đã viết cái gì nữa. Bởi thế, chúng ta nên suy nghĩ cách nghiêm túc về việc viết code sao cho chuẩn.

Thế nào là code chuẩn

Khi nhắc tới “viết code”, đừng nhắc tới ngay những thứ đao to búa lớn kiểu như: kiến trúc tổng quát của project, chọn lựa những mẫu thiết kế (design patterns), các kĩ thuật caching, .v.v.. Mặc dù những thứ này là quan trọng, nhưng hầu hết những vấn đề chúng ta gặp phải liên quan đến những thứ cơ bản hơn rất nhiều, ví dụ như:

• Đặt tên biến như thế nào cho dễ nhớ.
• Viết vòng lặp thế nào cho tối ưu.
• Có nên tách hàm nhỏ để xử lí hay là viết hết tất cả vào một nơi.
• Phân nhiệm vụ các modules thế nào?
• …

Nếu những thứ cơ bản chưa đảm bảo, đừng vội nói tới những thứ to lớn hơn.

Dưới đây là một vài cấp độ, mà theo mình thì tất cả chúng ta cần phải xem xét tới khi viết code, đó là:

• Mức 1 – nhập môn: Ở mức độ này, chúng ta quan tâm tới việc viết code cho dễ hiểu: đặt tên sao cho chuẩn, comment code sao cho dễ hiểu mà lại không quá dài, format code ngay ngắn … Mức độ này là bắt buộc với mọi người ở cấp cơ bản nhất.
• Mức 2 – học nghề: Lúc này, chúng ta quan tâm tới chi tiết hơn một chút xíu: viết vòng lặp sao cho tối ưu, tổ chức logic code tách bạch và rõ ràng, tối ưu các khối lệnh rẽ nhánh, quan tâm tới tính đơn nhiệm của hàm … Những người có ý định trở thành một lập trình viên nghiêm túc cần phải luyện kĩ mức này.
• Mức 3 – lành nghề: Tới mức này, chúng ta sẽ phóng tầm nhìn ra xa, nơi cấu trúc source code: tách các modules con với nhiệm vụ chuyên biệt, giảm thiểu sự phụ thuộc lẫn nhau của các thành phần, thiết kế component chung để tránh lặp code (DRY – Don’t Repeat Yourself), áp dụng các nguyên tắc thiết kế để đảm bảo tính mở rộng của ứng dụng, tối ưu code …. Cấp độ này mất khá nhiều thời gian, nhưng hãy kiên nhẫn và chăm chỉ.
• Mức 4 – sáng tạo: Tới đây, bạn đã phải làm chủ được kĩ thuật để tập trung vào việc sáng tạo “mĩ thuật”. Code viết ra không những đúng, đẹp, tối ưu mà còn khiến người đọc thấy sướng. Sử dụng thành thạo kĩ thuật, biết điểm mạnh yếu để áp dụng cho phù hợp với hoàn cảnh.

Viết code không khó, viết code chuẩn mới khó.

Mặc dù không dễ để có thể đạt được cảnh giới tối cao – sẽ mất rất nhiều thời gian và công sức – nhưng cái gì cũng có cái giá của nó, phần thưởng sẽ xứng đáng. Và mặc dù không có đường tắt nào cả, nhưng nếu chúng ta chăm chỉ đọc sách, học hỏi từ những người nhiều kinh nghiệm, chăm chỉ luyện tập … Cũng sẽ nhanh thôi.

Nói đơn giản hơn thì …

Ai cũng đều muốn code của mình “đẹp”, code của mình “chuẩn”, những tiêu chí nói ở trên quá dài để hiểu nhanh, vậy thì như thế nào mới được coi là “đẹp” và “chuẩn” nhỉ? Trước hết, điều căn bản của code “chuẩn” là:

Code có thể được người khác hiểu một cách dễ dàng

Một đoạn mã lệnh tốt trước tiên phải dễ hiểu, dễ hiểu bởi chính người viết ra nó, và cũng phải dễ dàng hiểu được với những người đọc nó. Tất nhiên, càng tới những cấp độ cao hơn thì code càng cần nhiều sức lực hơn để hiểu, nhưng hãy luôn làm nó đơn giản nhất ở mức độ của nó. Hãy luôn nhớ rằng: mọi thứ tự nhiên đều dễ hiểu. Hãy cố gắng vì điều đó.

Ranh giới giữa tốt và không tốt rất mong manh

Chúng ta thử xét ví dụ này nhé:

for( Node* node = list->head; node != NULL; node = node->next ){
    print( node->value );
}

và đoạn code tương tự:

Node* node = list->head;
if( node == NULL ) return;

while( node->next != NULL ){
    print( node->value );
    node = node->next;
}

if( node != NULL ) 
    print( node->value );

Có thể bạn sẽ đồng ý với mình rằng cách viết đầu tiên là tốt hơn nhiều so với cách viết thứ 2 phải không nào? Lí do là vì đoạn code thứ 2 quá rườm rà, và đôi khi còn dư thừa đoạn kiểm tra cuối nữa. Nhưng không phải là không có những ý kiến trái chiều: cách đầu tiên có vẻ như ngắn gọn hơn, thế nhưng cách thứ 2 lại có vẻ tường minh và dễ hiểu hơn. Đẩy vấn đề xa hơn một chút, chúng ta sẽ thắc mắc: tiêu chí nào sẽ được đánh giá cao hơn và nên ưu tiên hơn?

Theo mình thì không có câu trả lời nào là hoàn toàn đúng trong trường hợp này, mỗi người sẽ có 1 quan điểm riêng, và còn tuỳ vào mục đích của dòng code này để làm gì, và ai sẽ là người đọc nó nữa. Nhưng dù sao, hãy luôn nhớ câu thần chú này:

Những dòng code nên được viết sao cho người khác mất “ít thời gian nhất” để hiểu được chúng

“Người khác” ở đây hàm ý tới người không trực tiếp viết ra những dòng code này, hoặc cũng có thể là chính bạn 6 tháng sau đó, khi mà bạn đã gần như xa lạ với chính những dòng code của mình. Đôi khi ngắn nhất không phải là tốt nhất, “dễ hiểu nhất” cần được đặt lên hàng đầu. Không tin ư, hãy xem thử đoạn code sau:

assert( ( !( bucket = findBucket( key ) ) ) || !bucket->IsOccupied() )

Đoạn code trên sẽ tốn của bạn nhiều thời gian và “hoạt động của não” để hiểu các hoạt động và mục đích của nó hơn so với đoạn code sau đây:

bucket = findBucket( key );
if( bucket != NULL ) assert( !bucket->IsOccupied() );

Tổng kết

Mặc dù code ngắn gọn là một mục tiêu nên hướng tới, tuy nhiên thì tính dễ hiểu đôi khi còn là một mục tiêu quan trọng hơn. Nó sẽ giúp ích cho bạn rất nhiều sau này đấy. Hãy nhớ những tiêu chí và mức độ của “code chuẩn” mà mình đã chỉ ra ở trên để viết code cho tốt hơn, hãy luôn rèn luyện để tăng dần cấp độ nhé. Chúc vui!

<– *** –>

Tham khảo:
Sách: Clean Code: A Handbook of Agile Software Craftsmanship
Sách: The art of readable code