[Code sao cho chuẩn] – Bài 1: Hãy bắt đầu nghĩ tới việc viết code đẹp hơn và dễ hiểu hơn.

          Chắc hẳn với những người đã từng viết ra những dòng lệnh (code), đều đã từng đặt câu hỏi “code của mình viết thế này đã chuẩn chưa nhỉ?”. Hầu hết mọi người – đặc biệt là các bạn còn đang đi học hoặc mới vào nghề – đều nhiều lần tặc lưỡi nghĩ rằng “code chạy đã, đẹp xấu tính sau”, điều này dẫn tới việc có thể ngay chính bản thân họ 1 thời gian sau đó cũng không hiểu được họ đã viết cái gì nữa ^^. Bản thân mình đã từng như thế, và mình nhận ra việc ý thức viết những dòng code sao cho chuẩn rất quan trọng, và mình quyết định chia sẻ đôi điều về việc này.

          Một chút quy ước chung ở đây nhé, khi nhắc tới “viết code” có nghĩa là chúng ta đang nhắc tới việc viết những dòng mã lệnh cụ thể mà bạn đang trực tiếp gõ bàn phím để nhập liệu, chúng ta sẽ không nhắc tới những thứ đao to búa lớn kiểu như: kiến trúc tổng quát của toàn bộ project hay là việc chọn lựa những mẫu thiết kế (design patterns) cho project của bạn. 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 nhiều: đặt tên biến như thế nào cho dễ nhớ, viết vòng lặp thế nào cho chuẩn và tối ưu, có nên tách hàm nhỏ để xử lí hay là viết hết một mớ thứ hỗn độn vào 1 nơi (mà có thể bạn sẽ không bao giờ còn hiểu nó nữa ^^) …

preface
Hãy là một người viết code có tâm, vì biết đâu chính bạn sẽ phải đọc nó sau này ^^

          Theo cá nhân mình, những mức độ tốt mà tất cả chúng ta cần phải xem xét tới khi viết code đó là:

  • Mức độ gà còn trong trứng – tất cả mọi người phải có: đặt tên sao cho chuẩn, comment sao cho dễ hiểu mà lại không quá dài, format canh lề code cho chuẩn (chắc hẳn không ai muốn đọc những dòng code không được canh lề ngay ngắn), …
  • Mức độ gà thiếu nhi – những người đang hoặc sẽ dự định trở thành một lập trình viên nghiêm túc sau này: mức độ này chúng ta sẽ quan tâm tới việc viết vòng lặp sao cho tối ưu, tổ chức logic code tách bạch và hợp lí sao cho người khác có thể dễ dàng hiểu được ý đồ của mình, …
  • Gà tốt nghiệp – kĩ năng bắt buộc để trở thành một lập trình viên tốt: ở mức độ này, không những chúng ta chỉ viết kiểu “chạy được là ổn”, mà còn phải cấu trúc được source code, chuyên biệt hoá các nhiệm vụ con thành các hàm con tách biệt, tính tái sử dụng lại dễ dàng của source code cần được thể hiển ở mức độ này, ….
  •  Gà sư phụ – code viết ra không những tối ưu mà còn khiến người đọc thấy sướng: cái này chắc không đủ trình để nói rồi, cao nhân nào biết nhờ chỉ giúp ^^

          Ai cũng đều muốn code của mình “đẹp”, code của mình “chuẩn”, vậy thì như thế nào mới được coi là “đẹp” và “chuẩn” nhỉ? Theo mình mức độ cần thiết để đạt được điều này đó 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 dễ dàng hiểu được với những người không viết ra nó. Đã có bao giờ bạn được quăng một cái tập tin mã lệnh có độ dài lên tới hàng ngàn dòng code và bị bắt phải hiểu được logic của nó trong thời gian ngắn không? Chắc hẳn ai đã từng ở trong hoàn cảnh này mới hiểu rõ được giá trị của việc “code dễ hiểu” đáng giá như thế nào.

Vậy tiêu chuẩn gì để đánh giá 1 đoạn code này là “tốt hơn” một đoạn code khác?

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

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

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

While( node->next != NULL ){
    Print( node->value );
    Node = node->next;
}
If( node != NULL ) Print( node->value );

           Rõ ràng là bạn có thể thấy được là cách viết đầu tiên “tốt hơn” rất nhiều so với cách viết thứ 2 phải không nào? Thế nhưng đời không như là mơ, chúng ta thường gặp những trường hợp khó xử kiểu như sau đây nhiều hơn:

return exponent >= 0 ? mantissa * ( 1 << exponent ) : mantissa / ( 1 << exponent );

if( exponent >= 0 ){
    return mantissa * ( 1 << exponent );
} else {
    return mantissa / ( 1 << exponent );
}

          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. Thế thì tiêu chí nào được đánh giá cao 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. Sẽ là rất khác nếu bạn viết code để minh hoạ cho một lớp học “nhập môn” và một lớp học “nâng cao”. Thế thì chúng ta nên có một vài quy tắc chung để có thể có cùng một thước đo giá trị, và mình gọi nó là “lý thuyết cơ bản của những dòng code tốt”:

Những dòng mã lệnh nên được viết sao cho nó tối thiểu hoá thời gian mà “một người khác” có thể hiểu được chúng

          “Một 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 ^^.

          Nhiều người cho rằng: code ngắn hơn là code tốt hơn, mình e rằng nói vậy là quá vội vàng. Rất nhiều trường hợp đúng với câu nói đó, và tất nhiên cũng đầy rẫy trường hợp phản bác lại, và để mình nói cho bạn biết tại sao nhé. Bạn sẽ đồng ý với mình rằng, trong rất nhiều trường hợp thì đoạn code

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

         Sẽ tốn nhiều thời gian để hiểu hơn đoạn code:

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

          Hay là việc chèn một dòng chú thích sẽ khiến người đọc dễ hiểu hơn rất nhiều (so với việc không viết chú thích để code ngắn hơn):

//Fast version of: hash = ( 65599 * hash ) = c;
hash = ( hash <<  6 ) + ( hash <<  16 ) – hash + c;

          Vậy đó, 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ễ đọc hiểu” đôi khi còn là một mục tiêu quan trọng hơn. Để hướng tới việc tăng cường chất lượng những đoạn mã được viết ra, mình sẽ tiếp tục chia sẻ và bàn luận nhiều hơn ở những bài viết sau. Mọi người có ý kiến gì hay thì thảo luận chung với mình nhé. Cảm ơn vì đã theo dõi bài 🙂

Vcttai

Tham khảo:

Sách: Clean Code: A Handbook of Agile Software Craftsmanship

Sách: The art of readable code

5 thoughts on “[Code sao cho chuẩn] – Bài 1: Hãy bắt đầu nghĩ tới việc viết code đẹp hơn và dễ hiểu hơn.

    1. Đúng rùi đó bạn, đã edit:
      return exponent >= 0 ? mantissa * ( 1 << exponent ) : mantissa / ( 1 <
      –>
      return exponent >= 0 ? mantissa * ( 1 << exponent ) : mantissa / ( 1 << exponent );

      Cảm ơn bạn nhé 🙂

      Like

  1. Pingback: [Giới thiệu sách] The art of readable code – Cái tên đã nói lên tất cả – Webbynat

  2. Pingback: [Giới thiệu sách] Sách hay đầu năm 2017 (P1) – Những dòng code vui

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s