Clean code và những điều cơ bản cần biết
FCT Club xin giới thiệu bài viết của bạn Nguyễn Công Minh – Học viên Khóa II của CLB với chủ đề rất được quan tâm trong lập trình là “Clean Code”. Bài viết được tổng hợp dựa trên kiến thức và trải nghiệm của chính tác giả. Xin mời độc giả cùng đọc và chia sẻ quan điểm trong phần Bình luận dưới bài viết.
I. Clean code là gì, tại sao cần phải clean code?
Clean code nghĩa là cách tổ chức mã nguồn, cách triển khai mã nguồn sao cho khoa học, dễ hiểu và đem lại hiệu năng cao cho chương trình.
Chắc hẳn không ai muốn nhìn một đống code xấu (code smell) khi tham gia dự án hay code chung trong một nhóm, nó đem lại cảm giác khó hiểu và rất khó chịu cho người xem vì thế để code sạch (clean code) thì chúng ta cần phải biết những đặc điểm của nó và các giải pháp.
II. Mục đích của Clean Code
2.1. Giúp code dễ bảo trì hơn
– Bảo trì là quá trình điều chỉnh các lỗi chưa được phát hiện trong quá trình xây dựng phần mềm, nâng cấp tính năng của phần mềm, là một khâu quan trọng trong việc phát triển phần mềm. Vì vậy để dễ dàng điều chỉnh và sửa đổi thì code phải sạch, gọn gàng, dễ hiểu.
– Nếu không clean code thì code sẽ xấu và khó bảo trì. Vì người trước không clean code sẽ khó cho người sau hiểu và phát triển thêm, từ đó tạo một rào cản và khó khăn trong việc bảo trì. Trường hợp xấu nhất là phải làm lại từ đầu.
2.2. Giúp người khác đọc code dễ hơn
– Trong một dự án thường sẽ có nhiều người làm cùng nhau. Trong môi trường này, để đạt được hiệu quả cao thì mỗi người cần hiểu được code của nhau. Vì vậy, chúng ta cần đặt ra những quy tắc chung.
III. Một số quy tắc
3.1. Quy tắc đặt tên rõ nghĩa
– Tên của biến, hàm, hoặc class phải tự trả lời tất cả những câu hỏi về nó. Nó phải cho bạn biết lý do nó tồn tại, nó làm được những gì, và dùng nó ra sao. Nếu cần phải có một comment đi kèm theo tên, thì tên đó không thể hiện được mục đích của nó.
– Cần đáp ứng một số yêu cầu:
+ Dùng những tên thể hiện được mục đích
+ Tránh sai lệch thông tin
+ Tạo sự khác biệt rõ ràng
+ Dùng những tên phát âm được
+ Dùng những tên tìm kiếm được
3.1.1. Cách đặt tên biến, phương thức
– Tên hàm, tên phương thức nên sử dụng các động từ, thể hiện nó làm gì.
3.1.2. Cách đặt tên class
– Tên class nên sử dụng các danh từ, thể hiện nó là gì.
3.1.3. Một số cách đặt tên biến
– Pascal case: Cách đặt tên biến Pascal case phổ biến từ thời có ngôn ngữ lập trình Turbo Pascal. Pascal case yêu cầu chữ cái đầu tiên của một biến phải là chữ hoa và tương tự với chữ cái đầu tiên của mỗi từ được ghép với nhau để tạo ra biến.
VD: PascalCase
– Camel case: Camel case tuân theo các quy tắc tương tự như Pascal case nhưng bỏ yêu cầu viết hoa chữ cái đầu tiên, các chữ nó nhô lên như con lạc đà vậy.
VD: camelCase
– Snake case: Sử dụng dấu “gạch dưới” để ngăn cách các từ.
VD: SNAKE_CASE hoặc snake_case
– Kebab case: Sử dụng dấu “gạch ngang” để ngăn cách các từ.
VD: kebab-case
3.2. Tránh lạm dụng comment
“Đừng biến đống code gớm ghiếc của bạn thành comment – hãy viết lại nó”
BRIAN W. KERNIGHAN AND P. J. PLAUGHER
– Một comment tốt nên đặt đúng vị trí.
– Thay vì viết một hàm phức tạp, khó hiểu, hoặc một biến không rõ nghĩa mà chúng ta cần phải comment để giải thích thì chúng ta nên đơn giản hóa nó, làm cho nó dễ hiểu hơn.
3.2.1. Những trường hợp nên dùng comment
– Comment về pháp lý: Là các comment để cho người khác biết ai viết đoạn code đó.
– Các comment chứa thông tin: Là các thông tin khá hữu ích, cung cấp các thông tin cơ bản nhất về 1 hàm
– Giải thích thêm cho mục đích, quyết định
3.2.2. Bad comment
– Comment thừa: là những comment không có ý nghĩa.
– Commented-Out Code: là những đoạn code dưới dạng comment.
* Lưu ý: Đừng comment khi bạn có thể sử dụng biến để thay thế.
3.3. Nguyên tắc Clean Code với OOP
– Nguyên tắc SOLID:
+ Single responsibility priciple (đơn nhiệm): mỗi class chỉ nên giữ một trách nhiệm duy nhất ngoài class ra thì function cũng nên xử lý một việc không nên xử lý quá nhiều việc trong một class hay function.
+ Open/Closed principle (đóng/ mở): khi cần mở rộng một class, ta không nên sửa đổi code trong class đó mà nên viết một class mới mở rộng class cũ bằng cách kế thừa.
+ Liskov substitution principle (thay thế): một class con khi kế thừa lại class cha cần phải đảm bảo tính đúng đắn của chương trình.
+ Interface segregation principle: nên tách một interface lớn thành các interface nhỏ hơn, với nhiều mục đích cụ thể.
+ Dependency inversion principle (phụ thuộc): các class không nên phụ thuộc vào nhau, thay vào đó nên phụ thuộc vào Interface hoặc Abstract.
IV. Trải nghiệm của bản thân
– Trước khi tìm hiểu về Clean code thì mình thường có thói quen đặt tên biến sao cho ngắn gọn, dễ gõ khi code (ví dụ: a, b, c, n,… cho các biến về số, str0, str1,… cho các biến về chuỗi). Sau khi tìm hiểu thì mình nhận ra đó là những tên biến rất chung chung và khó quản lí, khó nhớ vì nó không thể hiện được mục đích của nó.
– Việc comment quá nhiều khiến mình bị phụ thuộc vào nó và giảm khả năng đọc hiểu code và hình thành các thói quen xấu khi xây dựng một phần mềm.
– Đôi khi mình thường hay viết những hàm đa nhiệm vì nó tiện lợi (thay vì chia thành nhiều func thì chỉ cần một func), nhưng nhược điểm của nó là sẽ tạo ra nhiều đoạn code trùng lặp nhau, khó hiểu cho người khác khi muốn biết mục đích của nó.
V. Tổng kết
– Clean Code là một kỹ năng quan trọng với mỗi lập trình viên, nó giúp ích cho chúng ta rất nhiều, đặc biệt là trong môi trường làm việc nhóm, xây dựng một phần mềm có chất lượng (dễ dàng sửa đổi, nâng cấp)…
2,395 total views, 3 views today