30/01/2024
CLEAN CODE - DỄ NHƯNG CHƯA CHẮC ĐÃ DỄ ĐÂU !
__________________________________
Clean Code đơn giản là "mã nguồn sạch" bao gồm cách tổ chức mã nguồn, cách viết mã khoa học, dễ đọc, dễ hiểu, dễ bảo trì và giúp tăng hiệu năng của chương trình. Đây cũng là một trong những vấn đề mà nhiều lập trình viên cần quan tâm
Clean code thực sự rất quan trọng, đặc biệt khi đi làm và bạn phải tham gia các dự án Technical có những file hàng ngàn dòng code. Và project thường có "code rule" với những quy định để code được "sạch" hơn.
Clean code còn đánh giá được trình độ của lập trình viên cũng như tính chuyên nghiệp của dự án. Ngoài ra còn có rất nhiều lợi ích khác đặc biệt là quá trình bảo trì, phát triển dự án trong tương lai.
Cùng mình tham khảo một số nguyên tắc để code được clean hơn nhé :
1. ĐẶT TÊN SAO CHO GỌN GÀNG, RÕ RÀNG, CHUYÊN NGHIỆP VÀ CÓ Ý NGHĨA
Có một câu nói được lan truyền trong cộng đồng lập trình viên: Chỉ có hai việc khó trong khoa học máy tính là loại bỏ cache hết hạn và đặt tên cho một thứ gì đó.
Đặt tên biến, hàm theo chuẩn Camel Case hoặc Snake Case, tùy theo ngôn ngữ lập trình. Ví dụ: firstName hoặc first_name.
Đặt tên có ý nghĩa, phản ánh chức năng hoặc giá trị của biến, hàm. Tránh sử dụng các tên biến chung chung, viết tắt hoặc không liên quan. Ví dụ: age hoặc customerName thay vì x hoặc a1.
Đặt tên theo quy ước của ngôn ngữ lập trình. Đặc biệt, tuân theo các quy tắc về cú pháp, kiểu dữ liệu, phạm vi và mục đích của biến. Ví dụ: MAX_VALUE hoặc PI cho các hằng số, i hoặc j cho các biến đếm, self hoặc this cho các biến tham chiếu đối tượng.
Đặt tên biến, hàm nhất quán và tránh sự nhầm lẫn. Không sử dụng các tên gần giống nhau, có nghĩa đối lập hoặc có thể gây hiểu nhầm. Ví dụ: sum hoặc total thay vì sum và summ, min hoặc max thay vì min và maxx, isValid hoặc isInvalid thay vì isValid và notValid. (trường hợp này hay gặp ở những bạn mới lập trình hoặc ở cả người lười như mình ahihi, sửa ngay nha)
2. HÀM CHỈ NÊN LÀM MỘT VIỆC DUY NHẤT
Hàm nên ngắn gọn và làm một việc duy nhất. Một hàm nên có ít dòng lệnh nhất có thể, và chỉ thực hiện một nhiệm vụ duy nhất. Điều này giúp có thể tái sử dụng hàm nữa. Vậy nên nếu hàm của bạn quá dài hoặc làm nhiều việc, bạn nên tách nó thành các hàm nhỏ hơn, mỗi hàm chỉ làm một việc.
Sử dụng tham số hợp lý. Một hàm nên có ít tham số nhất có thể, và tham số nên có ý nghĩa và kiểu dữ liệu phù hợp, có thể tránh sử dụng các tham số boolean, vì nó làm cho hàm của bạn có nhiều nhánh logic, dẫn đến khó hiểu và tiềm ẩn nhiều nguy cơ báo lỗi hơn.
Chữ ký của hàm thể hiện được nội dung cần thực thi. Sẽ còn tốt hơn nếu chỉ cần nhìn vào chữ ký của hàm, người đọc có thể đoán được các bước mà hàm sẽ thực hiện.
3. TRÁNH VIỆC LẶP CODE
Lặp code là khi bạn viết cùng một đoạn code nhiều lần ở nhiều nơi khác nhau, thay vì tái sử dụng nó bằng cách tạo ra một hàm, một lớp, một module hay một package. Việc này có thể sẽ dẫn đến các vấn đề sau:
Gây lỗi (bug) do code xử lý chồng chéo, không nhất quán hoặc không đồng bộ, khó kiểm soát chất lượng code, khó tìm và sửa lỗi khi phát sinh.
Khó bảo trì và mở rộng code, phải sửa đổi nhiều nơi khi có thay đổi yêu cầu.
Khó tái sử dụng code, phải viết lại code đã có sẵn ở nơi khác.
4. COMMENT CLEAN
Viết comments là một kỹ năng quan trọng trong lập trình, vì nó giúp code dễ đọc, dễ hiểu và dễ bảo trì hơn. Tuy nhiên, không phải comments nào cũng tốt, có một số lưu ý sau để cmt phát huy được đúng chức năng của nó:
Một comment nên cung cấp thêm thông tin cho code, không nên lặp lại những gì code đã nói, nên comments cho những đoạn code phức tạp, khó hiểu hoặc có ý nghĩa đặc biệt.
Bổ sung thông tin cho công việc. Một comment nên cung cấp thêm thông tin cho công việc, như người viết code, ngày viết code, mục tiêu, yêu cầu, giải pháp hoặc các vấn đề cần giải quyết.
Không dùng comment nếu có thể. Một comment nên chỉ được sử dụng khi cần thiết, không nên lạm dụng. Bạn nên cố gắng viết code rõ ràng, dễ hiểu và tự giải thích được, không cần phải dùng comment.
Loại bỏ các comment thừa, cũ, không còn cần thiết. Bạn sẽ không muốn giao diện code nhìn như trang nháp đâu...
5. NGUYÊN TẮC XỬ LÍ LỖI
Sử dụng exception thay vì trả về mã lỗi: Trong ngôn ngữ có exception, nếu bạn vẫn cố xuất lỗi bằng mã lỗi, đảm bảo rằng sau này đọc lại sẽ không thể biết nó là lỗi hay giá trị thực đâu!
Thêm thông tin về ngữ cảnh cho exception: Khi gặp lỗi, hãy cố gắng mô tả lỗi cho exception thật chi tiết, điều này rất quan trọng cho quá trình xử lí và fix bug sau này
Không nên bỏ qua lỗi: Do vô tình hay cố ý mà chúng ta thường bỏ qua lỗi, điều này sẽ gây khó khăn rất nhiều cho người bảo trì không thể tìm ra dấu vết xảy ra lỗi !
6. NGUYÊN TẮC VIẾT UNIT TEST
Chúng ta viết test để test chương trình đảm bảo đúng, vậy bản thân test phải ít sai sót nhất có thể, tức logic của unit test phải thật đơn giản. Có một số cách để làm được điều này:
Tổ chức các bước trong unit test theo pattern AAA (arange, act, assert).
Mỗi bài test nên chứa 1 lệnh assert và chỉ nên kiểm tra cho một trường hợp cụ thể.
NGUYÊN TẮC F.I.R.S.T
Nguyên tắc này là viết tắt của 5 từ :
• Fast: Unit test cần chạy nhanh để lập trình viên có thể chạy rất nhiều bài test trong thời gian ngắn.
• Independent: Các bài test không nên phụ thuộc vào nhau.
• Repeatable: Các bài test cần chạy một cách độc lập với môi trường bên ngoài để bài test có thể được chạy lặp đi lặp lại ở bất cứ môi trường nào mà không bị gián đoạn
• Self-Validating: Kết quả của bài test chỉ nên trả về là đúng hoặc sai.
• Timely: Các unit test cần được viết đúng thời điểm lý tưởng, phù hợp nhất là ngay trước khi viết production code. Bởi nếu viết test sau khi viết production code, dev rất dễ rơi vào tình huống khó tạo ra unit test cho production code đã viết.
Đây chỉ là một vài lưu ý ban đầu để code của chúng mình được gọn gàng và ngăn nắp, ngoài ra còn rất nhiều các lưu ý nữa và kinh nghiệm sẽ được rút ra trong quá trình học tập và làm việc.
Có khá nhiều sách về code sạch
Nguồn: Dev ơi mình đi đâu thế
