Code “đẹp trai” và code “xấu gái” – có gì hay ho?

0
161

Best coding practices

Trong sự nghiệp viết code, bạn có thể dễ dàng nhận thấy rằng dù viết bằng bất kỳ ngôn ngữ nào, sẽ luôn có những good code – tạm gọi là code “đẹp trai” và bad code – tạm gọi là code “xấu gái”. Cả hai loại code này đều có thể chạy đúng logic. Nhưng những code “xấu gái” lại gây ra một vấn đề lớn khi maintain dự án.

Trên thực tế, bất kể chương trình của bạn có chạy tốt tới đâu, vào một thời điểm nhất định nào đó sẽ có người nhúng tay vào việc đọc hoặc thay đổi lại code của bạn. Đó có thể là việc thêm vào những tính năng mới, sửa lại những 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 code của những người khác. Cuộc đời mà! Tóm lại, 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”.

Vậy, bạn có tưởng tượng được tầm quan trọng của code chất lượng cao? Để dễ hình dung hơn, hãy lật ngược vấn đề khi nghĩ tới hậu quả mà code “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à sự lãng phí thời gian để đọc hiểu, sửa chữa những đoạn code vô cùng “xấu gái”

Bạn viết một đoạn code và sau đó đoạn code đó đượ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 code của bạn thực sự rất quan trọng cho chính bạn và cả đồng nghiệp của bạn.

Có không ít lần mình bắt gặp các đồng nghiệp tán phét với nhau về việc họ không thể nhớ nổi đoạn code hay logic mà họ đã viết chỉ mấy ngày trước đó. Đối với một đoạn code “xấu gái”, bạn sẽ phải mất nhiều thời gian hơn để tìm được đáp án cho câu hỏi “mình đã làm cái quái gì vào lúc đó nhỉ?”. Nó tương tự với việc mọi thứ dần trở nên xáo trộn khi người nghệ sĩ không thể hiểu được chính tác phẩm của mình.

Để không rơi vào tình trạng đó, hãy chú ý và ghi nhớ những điều sau:

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 comment trong code. Comment giúp cho các đoạn code trở nên dễ hiểu và thuận lợi hơn cho việc bảo trì dự án sau này. Những dòng comment sẽ được đánh giá cao khi chỉ ra được tại sao phải viết code như thế này thay vì chỉ mô tả đoạn code 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 ngắn gọn và xúc tích nhất có thể, đừng dài dòng lê thê như viết văn bởi vì người đọc đã quá buồn ngủ khi đọc code rồi.

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

2. Nhớ viết code thụt dòng đúng chuẩn (Indention)

Indention

Một code được đánh giá là “đẹp trai” lý tưởng phải sở hữu đường cong “body” như trong hình. Điều này có nghĩa rằng chúng phải thể hiện được nơi đoạn code bắt đầu và kết thúc để bất cứ ai nhìn vào cũng có thể hiểu được và chiến được sau khi logic chương trình đã rõ ràng.

3. Chuẩn hóa file Readme’s

Sẽ là rất phức tạp nếu bạn có một project cần tiêu tốn hàng giờ để cài đặt môi trường và triển khai. Đây chính là lúc cần đến Readme như một vị cứu tinh. Để thuận lợi hơn, tốt nhất rằng 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ả chi tiết phần code của nó. Một Readme có cấu trúc chính xác như tại đây

4. Luôn đặt tên hàm, tên lớp theo chuẩn (Naming Conventions)

Rất nhiều lần chúng ta bắt gặp một class với cái tên ApiManager – cái tên chẳng hề 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 search trên Google từ khóa “best coding practice”.

Điều này giúp bạn phân biệt được khi nào và ở đâu một biến sẽ ra khỏi phạm vi chỉ bằng việc nhìn vào một block code. Tất cả tên của lớp, hay hàm(method, function) đề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 for : for(int i = 0; i< length; i++)).

Một cái tên tốt là cái tên mà khi đọc lên nó chứa đựng đầ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ể làm được nếu tuân thủ nguyên tắc “single responsibility”.

5. Hạn 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 chọn lựa, và 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 phá vỡ logic mọi thứ. Những con số ma thuật đó đều chẳng tốt đẹp gì, vì vậy hãy né chúng ngay để tự cứu lấy mình!

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

if(a < 8 && b < 8 && c < 8){
    do_something();
}

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

  • Thứ nhất: số 8 trong trường hợp này trở thành “magic number“. Khi bạn đọc qua đoạn code này, chắc chắn bạn không biết 8 đang biểu diễn cho cái gì (đối với tác giả đoạn code này thì đó là thời gian làm việc ban ngày của công nhân – 8 tiếng đồng hồ và chắc chỉ mình tác giả đoạn code 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 để code “đẹp trai” hơn, ta nên phẫu thuật chỉnh hình nó thành như sau:

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

if(a < WORK_HOURS && b < WORK_HOURS && c < WORK_HOURS){
    do_something();
}

6. Một số quy tắc khác

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

write good code
  • Code đẹp là một code được tổ chức tốt, được tổ chức tốt chứ không như một đống lộn xộn, mà giới developer thế giới hay nói là “spaghetti code” đó.
  • Code đẹp là code phải được test đầy đủ, 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”, “thông minh” đến mức người đọc không hiểu gì thì dù có chạy đúng logic chương trình vẫn là code “ngu”. Vì vậy chúng phải là những code hoạt động đơn giản nhất và rõ ràng nhất, đọc phát hiểu liền.
  • Code đẹp cần được thực hiện từ các đơn vị tính toán nhỏ nhất để 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 mình với mong muốn giúp các bạn tránh được những vấn đề phát sinh khi lập trì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 code “đẹp trai” nhất trong mắt tất cả mọi người.

Đừng quên chia sẻ bài viết nếu bạn cảm thấy hữu ích nhé!

Bình luận. Đặt câu hỏi cũng là một cách học

avatar
  Theo dõi bình luận  
Thông báo