11/10/2018, 21:21

Simple Rules For Simpler Code (P1)

Giới thiệu . Gần đây mình động chạm đến vấn đề, là làm cách nào đơn giản code mình đã viết hay không. Làm sao để nó càng đơn giản càng tốt, càng dễ hiểu càng tốt... chứ không phải càng cao siêu càng tốt hay hiệu xuất càng nhanh càng tốt. Giữa hai hoặc nhiều vấn đề, hiệu xuất hoạt động, ...

Giới thiệu .

  • Gần đây mình động chạm đến vấn đề, là làm cách nào đơn giản code mình đã viết hay không. Làm sao để nó càng đơn giản càng tốt, càng dễ hiểu càng tốt... chứ không phải càng cao siêu càng tốt hay hiệu xuất càng nhanh càng tốt.

  • Giữa hai hoặc nhiều vấn đề, hiệu xuất hoạt động, đơn giản, dễ hiểu, thì từ việc đơn giản code mình viết, nó sẽ làm cho việc đọc code dễ hiểu hơn, và nếu code đơn giản đến mức tối giản, thì hiệu xuất nó cũng chỉ có thể như vậy và không thể cải thiện thêm nữa. Mọi việc diễn ra luôn có thể xuất phát từ việc, làm sao để mình có thể viết code một cách đơn giản nhất có thể.

  • Động tới vấn đề này, thì hai cuốn sách đáng được đọc, và nên đọc là "The Art of Readable Code" và "Clean Code". Cũng may là có thể đọc một số chương bằng tiếng việt qua tác giả MinhNV, bạn này có đã đọc và dịch một số chương trong cuốn "Clean Code", tiếc là cuốn sách này bạn ấy dịch chưa hoàn thành, và một số chương bị nhảy chương. Nhưng cũng đáng để đọc và upvote cho tác giả về những cố gắng đó.

Viết code đơn giản hơn - Khởi điểm từ một bài hướng dẫn.

  • Việc đưa mình đến vấn đề làm sao để viết code càng đơn giản càng tốt, là một bài hướng dẫn về "các nguyên tắc để viết code đơn giản hơn", tác giả đề cập đến một số nguyên tắc để viết code đơn giản hơn. Tuy nhiên, bài giảng chỉ mang tính chất tham khảo là chính, vì theo mình, một số nguyên tắc này không dễ áp dụng và mất khá nhiều thời gian, cũng đòi hỏi phải là quá trình dài luôn luôn đặt cho mình câu hỏi: "Code của mình có thể cải thiện hơn cho nó đơn giản hơn hay không", và sau đó tái cấu trúc lại code... Mình sẽ tóm tắt một số nguyên tắc mà tác giả của bài giảng đã đề cập đến.

Nguyên tắc 1: Tránh viết tắt.

  • Bằng việc đưa ra một số ví dụ về cách đặt tên viết tắt ví dụ:
$tranl = a; // translator;
$cc = b; // clean code ;

sẽ có thể gây khó hiểu hơn cho code đang viết nếu không có comment (mà comment thì mình thêm vào).

Việc đặt tên biến (variable), hàm (function), class, function, ...mọi thứ cần được đặt tên mang tính gợi nhớ là một nguyên tắc chung và là nguyên tắc đơn giản và dễ nhớ, có thể áp dụng, và áp dụng nhiều nhất trong cách làm sao để viết code đơn giản và dễ hiểu.

Nhưng bài toán giữa độ dài của tên và mức độ gợi nhớ của nó cần được cân đối, và cũng là bài toán khó cân đối nhất trong khi đặt tên mang tính gợi nhớ. Nhất là đối với những người không có nhiều vốn từ vựng. Viết sao cho tên biến không dài từ địa đầu tổ quốc đến điểm cuối của tổ quốc, mà vẫn mang tính gợi nhớ, thì cần mọi người luyện tập trong thời gian dài. Với coder, việc code, và việc thực hiện rèn luyện này trong quá trình code gần như là một quá trình tự nhiên cần có, để có thể tiến bộ hơn.

Trong hai cực của vấn đề đặt tên mang tính gợi nhớ, thì việc cố gắng ưu tiên có tính gợi nhớ, đôi khi chúng ta sẽ chấp nhận một cái tên hơi dài một chút. Nhưng theo quan điểm của mình điều đó là ổn.

Nguyên tắc 2: Đừng dùng "Else"

  • Trong cấu trúc điều khiển logic thông thường, thì if-else là câu điều kiện đơn giản, dễ hiểu và dường như ngôn ngữ nào cũng cung cấp cấu trúc để thực hiện cấu trúc điều khiển if-else này.

  • Việc đừng dùng else ở đây nên được hiểu như sau:

     // Logic thông thường, ta sẽ có cấu trúc điều khiển điều kiện kiểu như sau: 
     if (điều kiện đúng) { // Nếu điều kiện này đúng
          // thực hiện khối lệnh này 
     } else if (điều kiện đúng thứ hai) { // Nếu điều kiện này đúng
         // thực hiện khối lệnh này
     } else { // Nếu không thực hiện khối lệnh này. 
     }
    

    Theo logic thông thường, thì khối lệnh if-else-if-else là không có gì sai, nó mang tính tự nhiên cao. Nhưng nếu chú ý một chút, thì thấy ngay rằng, nếu điều kiện trong if mà không đúng thì sẽ thực hiện việc thực hiện khối lệnh else. Như vậy, ta có thể bỏ else thì code sẽ trở lên đơn giản hơn, mà hoạt động vẫn đúng.

    if <điều kiện đúng> {
         // thực hiện lệnh
     }
     // thực hiện các lệnh nếu điều kiện không đúng.
    

    Bằng cách giản lược các khối lệnh else, chúng ta sẽ thực hiện việc làm cho code của chúng ta đơn giản hơn. Đơn giản ở đây không phải là việc số dòng code ít, mà đơn giản ở mức đọc hiểu, và logic vẫn hoàn toàn tự nhiên.

    Một số nguyên tắc ngoài lề với if-else

    • Tránh sử dụng phủ định trong điều kiện if. Hiểu nôm na là nếu sử dụng if (! false) {} thì hãy cố gắng tái cấu trúc lại code để không phải sử dụng như vậy.
    • Tránh sử dụng các if lồng nhau quá nhiều (nếu nhiều if hãy cân nhắc sử dụng cấu trúc switch-case nếu có thể)
    • Và nguyên tắc được đề cập ở đây, nếu bỏ được else thì hãy bỏ else đi.

Nguyên tắc 3: Chỉ thụt đầu dòng 1 lần (One Level of Indentation)

  • Điều này hiểu nôm na là hạn chế các cấu trúc điều khiển lồng nhau. Ví dụ:

    if <điều kiện đúng a> {
        // thụt đầu dòng lần 1
        if <điều kiện đúng b> {
             // thụt đầu dòng lần 2
             if <điệu kiện đúng c> {
                 // thụt đầu dòng lần 3
             }
        }
    }
    

    Thay vì cấu trúc trên, ta có thể là như sau:

    if <điều kiện đúng a> và < điều kiện đúng b> và <điều kiện đúng c> {
        // thực hiện khối lệnh ở thụt đầu dòng lần 3
    }
    
    if <điều kiện đúng a> và <điều kiện đúng b> {
        // thực hiện khối lệnh ở thụt đầu dòng lần 2
    }
    
    if <điều kiện đúng a> {
        // thực hiện khối lệnh ở thụt đầu dòng lần 1
    }
    

    Nếu thực hiện được nguyên tắc này, code chúng ta sẽ trở lên đơn giản hơn, dễ đọc hơn, dễ hiểu hơn.

    Nhưng thực tế, để làm được nguyên tắc này, không đơn giản như ví dụ mình đưa ra. Nhiều đoạn code, hay cấu trúc code, để có thể thực hiện chỉ thụt đầu dòng 1 lần, thì đòi hỏi phải có nền tảng kỹ thuật tốt, có tư duy, và đôi khi cần cả sự tinh tế cần thiết nữa.

    Cần kiên trì, và chú ý thực hiện điều này trong code của mình, thì việc này sẽ trở thành thói quen, và cải thiện đáng kể chất lượng các dòng code mà mình viết ra. Tuy nhiên, bạn không thể quá chăm chú vào code làm sao cho đẹp, cho dễ hiểu nếu bị deadline ngồi trên vai và chỉ đạo bạn code.             </div>
            
         </div>
      </div>
      
      
      <div class=

Bài liên quan

Simple Rules For Simpler Code (P1)

Giới thiệu . Gần đây mình động chạm đến vấn đề, là làm cách nào đơn giản code mình đã viết hay không. Làm sao để nó càng đơn giản càng tốt, càng dễ hiểu càng tốt... chứ không phải càng cao siêu càng tốt hay hiệu xuất càng nhanh càng tốt. Giữa hai hoặc nhiều vấn đề, hiệu xuất hoạt động, ...

Trịnh Tiến Mạnh viết 21:21 ngày 11/10/2018

6 điều tôi vỡ lẻ khi tự học code (P1)

Nguồn ảnh: REUTERS/Kacper Pempel Tôi được khuyến khích và muốn chia sẻ kinh nghiệm của mình để bản thân vui hơn, vì vậy tôi viết bài này để các bạn đến sau hiểu được nhiều hơn con đường mình đi. Hãy lưu ý rằng chuyên ngành của tôi là phát triển web, vì vậy stack của tôi phản ánh điều đó. ...

Trần Trung Dũng viết 22:38 ngày 08/09/2018

3 simple rules để trở thành git Master

Ở bài viết này tôi muốn trình bày về 3 simple rules để giúp bạn trở thành một Git Master Mình sẽ không trình bày về các thao tác với Git ở đây nếu bạn chưa quen với Git thì có thể tham khảo trang chủ của Git Không đợi gì nữa chúng ta sẽ bắt đầu luôn. Rule 1: Tạo một Git repository cho mọi new ...

Vũ Văn Thanh viết 08:46 ngày 07/09/2018

Introduce about Dropwizard, a simple library for RESTful web services

Mình đang tham gia một dự RESTful API khách hàng chọn Dropwizard để phát triển, nó khá lạ lẫm với chúng ta. Tìm hiểu trên github hay trang chủ cũng chỉ có thông tin cơ bản. Github: https://github.com/dropwizard/dropwizard Doc: https://www.dropwizard.io Nhưng trải qua thời gian nghiên cứu và làm ...

Bùi Văn Nam viết 18:24 ngày 12/08/2018

Top 8 tools for Ruby on Rails code optimization and cleanup

Giữ code của bạn sạch sẽ và tổ chức cấu trúc tốt trong khi phát triển một ứng dụng Rails lớn là một thách thức ngay cả đối với một lập trình viên có kinh nghiệm. Thật may mắn, có một số gem giúp chúng ta trong công việc này trở nên dễ dàng hơn. Đa số lập trình viên đều tạo ra những "mã chết" ...

Tạ Quốc Bảo viết 15:23 ngày 12/08/2018
0