Viết clean code: Code “đẹp trai” và code “xấu gái” có gì hay ho?

Trong sự nghiệp viết mã, bạn sẽ nhận ra là bất kỳ ngôn ngữ nào, sẽ luôn có mã tốt – tạm gọi là mã “đẹp trai” và mã xấu – tạm gọi là mã “xấu gái”. Cả hai loại mã này đều có thể chạy đúng logic. Nhưng những mã “xấu gái” lại gây ra một vấn đề lớn khi duy trì dự án. Dưới đây là một số kinh nghiệm viết clean code cho dự án.

Lập trình viên có nên trau chuốt khi viết mã?

Trên thực tế, bất kể chương trình của bạn chạy tốt đến đâu, vào một thời điểm nhất định nào đó sẽ có người nhúng tay vào công việc đọc hoặc thay đổi lại mã của bạn.

Có thể là thêm tính năng mới, sửa lỗi hoặc đơn giản chỉ là đọc để hiểu rõ “đứa con” của bạn hoạt động như thế nào.

Ngược lại, sẽ có lúc bạn cũng phải làm điều tương tự với mã của những người khác.

Mọi chuyện sẽ thuận lợi hơn nếu bộ code dễ đọc và dễ hiểu, hay nói cách khác là code phải “đẹp trai”.

Bạn có tưởng tượng được tầm quan trọng của mã chất lượng cao không? Do đó, hãy đảo ngược vấn đề khi nghĩ tới hậu quả mà mã “xấu gái” có thể mang tới. Đó chính là sự tổn thất về tiền bạc, nhân lực và thời gian lãng phí để đọc hiểu, sửa chữa những đoạn mã vô cùng “xấu gái”.

Bạn viết đoạn mã và sau đó đoạn mã đó được sử dụng ở rất nhiều nơi trong dự án. Do đó việc cung cấp những thông tin cần thiết về đoạn mã của bạn thực sự rất quan trọng đối với chính bạn và cả đồng nghiệp của bạn.

Đã không ít lần mình bắt gặp các đồng nghiệp tán phét với nhau về công việc mà họ không thể nhớ nổi đoạn code hay logic mà họ đã viết chỉ vài ngày trước đó.

Đối với một đoạn mã “xấu gái”, bạn sẽ phải mất nhiều thời gian hơn để tìm được câu trả lời cho câu hỏi “ mình đã làm cái quái gì vào lúc đó nhỉ? ”

Một số lời khuyên viếtn Clean code - mã sạch gọn gàng, mạch lạc

#1. Hãy viết “còm men” một cách khoa học

Hầu hết các ngôn ngữ hiện nay đều hỗ trợ viết bình luận trong mã. Comment giúp cho các đoạn mã trở nên dễ hiểu và thuận lợi hơn cho việc bảo đảm dự án sau này.

Những dòng bình luận sẽ được đánh giá cao khi chỉ ra được tại sao phải viết mã như thế này thay vì chỉ mô tả đoạn mã này làm nhiệm vụ gì. Bởi vì người ta đọc code là người ta đã hiểu code làm gì rồi đâu cần giải thích lại.

Việc comment cũng cần phải rút gọn và xúc tích nhất có thể, đừng dài dòng lê thê như viết văn vì người đọc đã quá buồn ngủ khi đọc code rồi.

Bình luận tốt là bình luận giải thích được tại sao mọi thứ đều được làm như vậy. Bạn không phải nói chỗ này làm gì, có tác dụng gì, tự bản thân mã đã nói lên được điều đó rồi.

#2. Ghi mã nhận dòng đúng chuẩn (Indention)

Một mã được đánh giá là “đẹp trai” lý tưởng phải sở hữu đường cong “cơ thể” như trong hình. Chúng ta phải thể hiện được nơi đoạn mã bắt đầu và kết thúc để bất cứ ai nhìn vào cũng có thể hiểu được. Khi hiểu được thì việc tiếp tục phát triển chương trình sẽ đơn giản hơn rất nhiều.

#3. Chuẩn hóa tệp Readme's

Sẽ rất phức tạp nếu bạn có một dự án cần tiêu tốn hàng giờ để cài đặt môi trường và khai thác. Đây chính là lúc cần đến Readme với tư cách là một cứu tinh.

Tốt nhất bạn nên viết một đoạn giới thiệu ngắn gọn về dự án trước khi mô tả phần mã.

#4. Luôn đặt tên hàm, tên lớp theo tiêu chuẩn (Quy ước đặt tên)

Rất nhiều lần chúng ta bắt gặp một lớp với cái tên ApiManager – cái tên đó chẳng phải đã thể hiện được mục đích rõ ràng của lớp đó.

Bạn nên tham khảo quy tắc đặt tên bằng cách tìm kiếm trên Google từ khóa “ thực hành viết mã tốt nhất ”.

Điều này giúp bạn phân biệt được khi nào và ở đâu một biến sẽ thoát khỏi phạm vi chỉ bằng cách nhìn vào một mã khối.

Tất cả tên của lớp hay hàm(phương thức, chức năng) đều phải có ý nghĩa. Đọc là hiểu tác dụng chính của nó, ngoại trừ những đối tượng tạm thời (ví dụ như tên biến trong vòng cho:

cho ( int i =  0 ; i < độ dài ; i ++ )

Một cái tên tốt là cái tên mà khi đọc lên nó chứa đầy đủ thông tin về công dụng cũng như cách sử dụng và điều này chỉ có thể thực hiện được nếu hành thủ nguyên tắc “trách nhiệm duy nhất”.

#5. Chế độ tối đa Magic Numbers

Magic Numbers tức là bạn tự định nghĩa một hằng số và chương trình sẽ chỉ chạy đúng với hằng số đó.

Không ai có thể biết được tại sao con số đó được lựa chọn. Không ai thực sự biết được những con số ảnh hưởng đến chương trình như thế nào. Ngoại trừ việc thay đổi chúng, đồng nghĩa với việc phá vỡ logic mọi thứ.

Những con số ma thuật đó đều tốt đẹp cả. Vì vậy, hãy né chúng tôi ngay để tự cứu lấy mình!

Mình lấy một ví dụ với đoạn mã sau:

nếu ( a <  8 && b < 8 && c < 8 ) {     do_something ( ) ; }

Ta thấy command so sánh giá trị 3 biến a,b,c với số 8 tồn tại trong 2 vấn đề.

Thứ nhất : số 8 trong trường hợp này trở thành " con số kỳ diệu ". Khi bạn đọc qua đoạn mã này, chắc chắn rằng bạn không biết 8 đang biểu diễn cho cái gì. Đối với tác giả đoạn mã này thì đó là thời gian làm việc cấm ngày của công nhân – 8 tiếng đồng hồ và chắc chỉ mình tác giả đoạn mã này thực sự biết điều đó
Thứ hai : số 8 được lặp lại 3 lần ở các phép so sánh. Như vậy, khi cần thay đổi giá trị 8 thành 7 hoặc tăng lên 12 chẳng hạn, ta sẽ phải đi dò từng vị trí mà 8 xuất hiện… Rất bất tiện và dễ phát sinh lỗi.

vì vậy để viết mã sạch hơn, ta nên phẫu thuật chỉnh sửa cấu hình của nó thành như sau:

// Số giờ làm việc trong ngày của công nhân cuối cùng int WORK_HOURS = 8 ;
  

nếu ( a < WORK_HOURS && b < WORK_HOURS && c < WORK_HOURS ) {     do_something ( ) ; }

#6. A number of rule other

Và thật ra còn hàng phần trăm hàng nghìn thứ khác để giúp code chúng ta trở nên đẹp tinh tế hơn. Viết clean code cho đẹp là cả một quá trình. Để biên lại, mình có một số ý kiến sau.

Code đẹp là code được tổ chức tốt. Đừng để code của bạn trở thành một đống lộn xộn, mà giới lập trình viên hay gọi là “mã spaghetti”.
Code đẹp là code must be comment full. Comment tại sao lại viết mã như thế, thay vì mã đó chạy như thế nào. Tốt hơn hết là nên có ví dụ về cách sử dụng.
Code đẹp không phải là code “thông minh”. Mã “thông minh” đến mức người đọc không thể hiểu nổi. Thì dù có chạy đúng logic vẫn là mã “ngu”. Vì vậy, nên viết mã thật đơn giản và rõ ràng, đọc hiểu liền kề.
Mã đẹp cần được thực hiện từ các đơn vị tính toán nhỏ nhất. Tức là mỗi chức năng chỉ làm một việc thôi, để nó có thể tái sử dụng nhiểu nhất có thể.

Trên đây là toàn bộ những chia sẻ của IGB về kinh nghiệm viết clean code. Hi vọng nó sẽ giúp các bạn tránh được những bug tàng hình.
Với những lưu ý kể trên, hãy cùng cố gắng để trở thành cha đẻ của những mã “đẹp trai” nhất trong mắt tất cả mọi người.

Thu Hiền

>> Xem thêm: