Hướng dẫn cách viết code "clean" - code sạch và hiệu quả

Việc code "clean" chắc hẳn đã làm nhiều lập trình viên bạc đầu để nghĩ cách làm sao cho mã code của mình dễ đọc, dễ hiểu, dễ bảo trì và hiệu suất tốt. Nhằm giảm thiểu thời gian mày mò, tìm kiếm cho các coder, TTLab Academy sẽ hướng dẫn các bạn cách viết code "clean" dễ hiểu nhất nhé!

Vì sao cần viết clean code ?

Đầu tiên, chúng ta sẽ trả lời câu hỏi tại sao chúng ta cần "clean code" (code sạch)? Đó là vì các lý do sau:

• Tăng hiệu suất làm việc: Code sạch và dễ hiểu giúp lập trình viên dễ dàng tiếp cận, hiểu và thao tác với code hơn. Điều này giảm thời gian cần thiết để đọc hiểu và sửa lỗi, cho phép lập trình viên tập trung vào việc phát triển tính năng mới.
• Dễ dàng bảo trì và mở rộng: Code sạch là code dễ bảo trì. Khi hệ thống phát triển lên hoặc cần thêm tính năng mới, việc đảm bảo clean code giúp lập trình viên dễ dàng thực hiện mà không gây ra lỗi đối với tính năng cũ.
• Tăng khả năng tái sử dụng: Viết code theo nguyên tắc DRY (Don't Repeat Yourself) là một phần quan trọng của việc viết code clean. Điều này không chỉ giúp giảm lượng code mà còn tạo ra các hàm hoặc module có thể tái sử dụng ở nhiều nơi trong dự án, thậm chí có thể tái sử dụng ở các dự án khác.
• Tăng tính cộng tác: Khi làm việc theo nhóm, mã code của bạn sẽ không chỉ được bạn đọc và sử dụng mà còn có những người khác. Clean code giúp người khác dễ dàng đọc và hiểu mã của bạn, tăng khả năng cộng tác và hiệu quả làm việc của cả nhóm.
• Giảm rủi ro và chi phí: Clean code giúp giảm rủi ro phát sinh lỗi và giúp dễ dàng phát hiện lỗi nếu có. Điều này cũng giúp giảm chi phí cho việc bảo dưỡng và sửa chữa lỗi trong tương lai.

Nhìn chung, việc viết code sạch (clean) là một phần quan trọng trong việc phát triển phần mềm chất lượng cao. Điều này đòi hỏi sự kiên nhẫn, kỹ năng và thực hành liên tục từ lập trình viên.

Dưới đây là các nguyên tắc giúp bạn đảm bảo được "clean code"

Đảm bảo tính nhất quán trong toàn bộ dự án

Tính nhất quán là một trong những nguyên tắc cơ bản để đảm bảo clean code. Trước khi bắt đầu thực thi việc phát triển bất kỳ một dự án nào, chúng ta cần đưa ra các quy định cho mọi thành viên trong dự án phải tuân thủ. Các quy định đó bao gồm:

Quy định về định dạng code (formatting): Dự án nào cũng cần tuân theo một bộ quy tắc định dạng nhất định, bao gồm việc thụt lề và khoảng trắng, đặt dấu ngoặc, độ dài dòng, v.v. Quy định này giúp code trở nên dễ đọc hơn và dễ dàng nhận biết lỗi cú pháp. Tùy thuộc vào ngôn ngữ lập trình bạn đang sử dụng thì có sẽ những công cụ hữu ích tương ứng giúp bạn đảm bảo rằng code được tuân theo một tập quy tắc mà bạn định ra, hầu hết các công cụ này đều có thể tích hợp với các trình soạn thảo code (ví dụ: Visual Studio Code, Atom, Sublime Text, etc.) để tự động định dạng code khi bạn lưu file hoặc trước khi bạn commit code lên repository. Ví dụ một số công cụ phổ biến:

• Prettier, ESLint cho JavaScript
• Black cho Python
• gofmt, goimports cho Golang
• ClangFormat cho C, C++, Objective-C, Java

Quy định về việc đặt tên: Việc đặt tên biến, tên hàm, tên lớp, tên file, tên folder, tên bảng, tên cột, tên router/api url... phải được quy định một kiểu đặt tên cụ thể và phải áp dụng kiểu đó trong suốt quá trình phát triển dự án. Một số quy chuẩn đặt tên phố biến:

• Camel case (ex: productList, userLoginCount) thường được sử dụng để đặt tên biến, tên hàm trong một số ngôn ngữ lập trình như JavaScript, Java ...
• Pascal case (ex: ProductList UserLoginCount) thường được sử dụng để đặt tên class, component
• Snake case (ex: product_list, user_login_count, PRODUCT_LIST, USER_LOGIN_COUNT) khi viết hoa thường được dùng để định nghĩa các hằng số (constant), viết thường được dùng để định nghĩa tên hàm, tên biến trong một số ngôn ngữ lập trình như python, php
• Kebab case (ex: product-list, user-login-count) thường được sử dụng để đặt tên folder, tên router/api url
• Quy định về tổ chức source code: Mỗi dự án cần phải có quy định về việc tổ chức source code cụ thể, ví dụ như quy định về tổ chức file, folder, tổ chức 1 module gồm các thành phần nào, các function sử dụng chung đặt ở đâu, ... Tùy vào từng dự án sẽ có các tổ chức khác nhau, điều bạn cần làm là phải xác nhận về quy định với trưởng nhóm dự án và tuân thủ.
• Quy định về việc viết comment (chú thích): Comment (chú thích) trong code cũng nên nhất quán về cách sử dụng và cấu trúc. Chú thích hữu ích không chỉ giải thích "cái gì" mà còn "tại sao", giúp những người khác trong nhóm dễ dàng hiểu hơn về mục đích của một đoạn code cụ thể.

Nhớ rằng, mặc dù tính nhất quán rất quan trọng, nhưng nó không nên trở thành một ràng buộc cứng nhắc. Một số trường hợp có thể đòi hỏi phải điều chỉnh quy tắc, miễn là điều đó giúp làm cho code dễ đọc, dễ hiểu và dễ bảo trì hơn.

Đặt tên một cách có ý nghĩa

Việc đặt tên biến, hàm, lớp, file, folder một cách có ý nghĩa là một phần quan trọng để đảm bảo "clean code". Dưới đây là một số nguyên tắc chung mà bạn nên tuân thủ khi đặt tên:

• Rõ nghĩa: Tên nên mô tả rõ ràng ý nghĩa của biến, hàm, lớp, ... Không đặt những tên mang ý nghĩa chung chung như value, handle, process ...hoặc những tên vô nghĩa như a, gsagst, ... Ví dụ, nếu bạn đặt tên một biến là d, người khác không thể hiểu được nó đại diện cho gì. Tuy nhiên, nếu bạn đặt tên là numberOfDays, mọi người sẽ dễ dàng hiểu được nó là gì.
• Sử dụng ngôn ngữ tiếng Anh chuẩn: Đặt tên theo tiếng Anh chuẩn để đảm bảo mọi người, kể cả những người không nói tiếng Anh là ngôn ngữ mẹ đẻ, đều có thể hiểu được
• Tuân thủ quy ước của ngôn ngữ lập trình: Mỗi ngôn ngữ lập trình đều có quy ước riêng về cách đặt tên. Ví dụ, trong Java, tên biến và phương thức thường sử dụng camelCase, tên lớp sử dụng PascalCase, trong Python, tên biến và hàm thường sử dụng snake_case...
• Tránh viết tắt: Viết tắt có thể gây nhầm lẫn và khó hiểu, và để hình thành thói quen không viết tắt, cho dù là 1 từ viết tắt phổ biến bạn cũng không nên sử dụng
• Đặt tên phù hợp với loại từ:

               - Tên hàm thì bắt đầu bởi động từ hoặc cụm từ bắt đầu bằng động từ vì hàm thực hiện một hành động.

               - Tên lớp, tên biến thường là danh từ vì nó đại diện cho một đối tượng hoặc khái niệm.

               - Biến boolean thì nên bắt đầu bởi is, hoặc has

• Đặt tên dễ đọc:

               - Tên phải dễ đọc và dễ hiểu cho bất kỳ lập trình viên nào đọc code của bạn, không chỉ riêng bạn.

               - Không được đặt tên mà không thể phát âm được, ví dụ: genymdhms

• Thống nhất thuật ngữ sử dụng: Có nhiều từ đồng nghĩa với nhau (ví dụ: get, fetch, retrieve), bạn cần thống nhất chỉ sử dụng 1 từ trong toàn bộ dự án

Đảm bảo function (hàm) đơn giản nhất có thể

Mỗi hàm chỉ nên có 1 nhiệm vụ duy nhất, nguyên tắc này rất quan trọng bởi vì nó giúp code dễ hiểu và bảo trì hơn. Khi hàm nhỏ/đơn giản, chúng sẽ dễ đọc và hiểu hơn bởi vì chúng tập trung vào một công việc duy nhất. Điều này có thể giúp lập trình viên nhanh chóng xác định công việc của hàm và cách nó liên quan đến phần còn lại của dự án. Ngược lại, hàm lớn sẽ làm gia tăng độ phức tạp và khó theo dõi, dẫn đến nhiều sự nhầm lẫn và lỗi.

Khi hàm chỉ làm 1 nhiệm vụ duy nhất cũng sẽ tăng khả năng tái sử dụng.

Vì vậy nếu bạn thấy hàm của bạn làm nhiều hơn 1 nhiệm vụ thì sẽ cần phải tách ra làm nhiều hàm nhé.

Ví dụ:

Hãy xem xét một hàm lớn và phân tách nó thành nhiều hàm nhỏ.

Giả sử bạn có một hàm processData() như sau:

Hàm trên thực hiện ba bước: làm sạch dữ liệu, thực hiện một số tính toán phức tạp và sau đó tạo ra một báo cáo. Mỗi bước trong hàm này có thể được phân tách thành một hàm riêng biệt như sau:

Bây giờ, processData() có thể gọi các hàm này một cách rõ ràng:

Với cách viết này, mỗi hàm đều tập trung vào một tác vụ cụ thể và processData() trở nên rõ ràng và dễ đọc hơn. Mỗi hàm nhỏ cũng dễ dàng kiểm tra, bảo trì và tái sử dụng.

Sử dụng nguyên tắc DRY (Don't Repeat Yourself)

Hãy cố gắng tránh lặp lại cùng một đoạn mã ở nhiều nơi khác nhau. Khi thấy có 1 đoạn mã được sử dụng từ 2 chỗ trở lên, hãy tạo một hàm hoặc lớp và gọi chúng. Nguyên tắc này giúp mã của bạn dễ bảo trì và tránh lỗi.

Viết comment (chú thích) có ý nghĩa

Viêt chú thích (comment) một cách có ý nghĩa là kỹ năng quan trọng cho mọi lập trình viên. Tuy nhiên không phải code nhiều comment có nghĩa là tốt, nếu bạn đặt tên biến, hàm, lớp ... đúng và rõ nghĩa thì việc comment là không cần thiết.

Dưới đây là một số hướng dẫn để bạn viết comment có ý nghĩa:

• Viết chú thích bằng từ ngữ đơn giản, ngắn gọn và súc tích. Không dùng từ lóng hoặc những từ vựng phức tạp, không ghi chú thích cá nhân, những lời nhận xét hoặc bông đùa.
• Không viết comment lặp lại code hoặc không cung cấp thêm thông tin so với code, ví dụ như đoạn comment dưới đây là không cần thiết:

• Sử dụng đúng ngữ pháp và dấu câu. Điều này làm tăng mức độ dễ đọc và tăng giá trị của comment.

• Viết đủ comment cho các lớp (class), hàm (function), bao gồm mô tả ngắn gọn về chức năng để những người khác có thể hiểu mục đích của các lớp, hàm này. Đây là những trường hợp phổ biến cần có comment.

• Trong một số trường hợp, thay vì tự viết code thì bạn sẽ copy từ một nguồn nào khác, khi đó, bạn cần comment cung cấp thông tin tới nguồn mà bạn sử dụng. Ví dụ:

• Khi có comment như thế này sẽ giúp những người khác (và cả bạn sau này) hiểu được:

               - Vấn đề gì đã được giải quyết

               - Ai cung cấp mã (code)

               - Tại sao giải pháp được khuyến nghị

               - Những người khác bình luận gì về giải pháp này

               - Kiểm tra được đoạn code này vẫn hoạt động hay không

               - Xem các phương án cải thiện

• Bạn nên viết comment cùng thời điểm với khi bạn code, khi có cập nhật code thì cần phải cập nhật comment.

• Sử dụng comment để đánh dấu những đoạn code chưa hoàn thành hoặc đang có những vấn đề cần lưu ý: bạn nên sử dụng các thẻ như TODO, FIXME, BUG,... ; tùy thuộc vào từng trường hợp mà sử dụng thẻ tương ứng. Hầu hết các IDE đều hỗ trợ việc hiển thị nổi bật (highlight) và tìm kiếm nhanh các đoạn comment dùng thẻ này. Ví dụ:

Việc viết chú thích (comment) rõ ràng là một khía cạnh quan trọng của "clean code", nhưng việc viết chú thích không nên bị lạm dụng. Việc viết chú thích nên tập trung vào giải thích "tại sao" (Code Tells You How, Comments Tell You Why) một cách rõ ràng, ngắn gọn, và cần được cập nhật liên tục cùng quá trình code. Bạn nên nhớ rằng code rõ ràng và ngắn gọn là tốt hơn code có nhiều chú thích (comment). Mục tiêu của viết code là code tự giải thích và dễ đọc. Nếu một đoạn code cần phải được chú thích nhiều để hiểu thì có thể là dấu hiệu rằng code cần được tái cấu trúc hoặc đơn giản hóa.

Không sử dụng "Magic Number"

Trong lập trình, "magic number" là một số không có giá trị rõ ràng hoặc không được mô tả trực tiếp, thường được sử dụng trực tiếp trong code mà không có bất kỳ giải thích nào.

Ví dụ, trong đoạn mã sau:

Ở đây, 0.2 là một "magic number" - nó không có mô tả nào và người đọc code có thể không biết nó đại diện cho gì khi không có bối cảnh hoặc tài liệu thêm.

Một cách tốt hơn để viết code trên là sử dụng một hằng số có tên rõ ràng để thay thế cho "magic number", ví dụ như sau:

Trong trường hợp này, TAX_RATE được định rõ là 0.2, giúp người đọc code dễ hiểu hơn về mục đích của số này.

Nói chung, việc tránh sử dụng "magic number" giúp code của bạn dễ đọc và bảo trì hơn.

Không để lại những đoạn code thừa, không comment code

Nhiều bạn khi gặp tình huống là đoạn code đã không còn sử dụng nữa thì thay vì xóa đi lại comment code, tức là đã biến một đoạn code hoạt động thành một đoạn chú thích, có thể hữu ích trong quá trình phát triển, khi bạn muốn tạm thời ngưng sử dụng một phần code mà không muốn xóa hoàn toàn nó. Tuy nhiên, để những dòng code đã comment tồn tại lâu dài trong code là một thói quen không tốt vì một số lý do sau:

• Làm rối code: Code đã được comment out không có chức năng gì trong chương trình và chỉ làm cho code trở nên lộn xộn hơn, khó đọc hơn.

• Tạo ra sự hiểu lầm: Có thể khó để biết tại sao một phần code đã được comment out. Có phải vì nó gây ra lỗi, hay vì nó không còn cần thiết nữa, hay chỉ là một ý tưởng chưa hoàn thiện? Nếu những lập trình viên khác gặp phải phần code đã comment này, họ có thể sẽ mất thời gian để hiểu ra vấn đề.

• Làm mất lịch sử code: Hầu hết các dự án phát triển phần mềm đều sử dụng các hệ thống quản lý phiên bản như Git, cho phép bạn xem lại lịch sử thay đổi của code. Nếu bạn xóa một dòng code thì quyết định đó sẽ được ghi lại, và bạn có thể khôi phục dòng code đó sau này nếu cần. Nhưng nếu bạn chỉ comment dòng code thì lịch sử thay đổi đó sẽ không rõ ràng.

• Bảo trì code: Code đã comment cũng cần được bảo trì. Khi chương trình thay đổi, code đã comment có thể trở nên lỗi thời và không còn hợp lệ.

Vì các lý do trên, thay vì comment code, bạn nên xóa nó. Nếu sau này bạn cần sử dụng lại, hãy sử dụng hệ thống quản lý phiên bản (ví dụ Git) để khôi phục lại.