- vừa được xem lúc

Clean Code: 7 tips to write clean functions

0 0 2

Người đăng: kentrung

Theo Viblo Asia

Motivation

Nếu mất hơn 3 giây để hiểu một hàm làm gì, đã đến lúc bạn nên tái cấu trúc nó. Chất lượng hàm của bạn tỉ lệ nghịch với thời gian cần để hiểu chúng.

Các hàm phức tạp có thể dẫn đến lỗi, làm cho việc thay đổi trở nên khó khăn và làm chậm quá trình làm quen cho các developer khác. Hãy nhớ rằng, mã nguồn được đọc nhiều hơn là viết, vì vậy đầu tư thời gian vào việc viết các clean functions là một trong những khoản đầu tư tốt nhất mà bạn có thể thực hiện trong thời gian dài.

Dưới đây là 7 mẹo về cách tôi viết clean functions.

1. Keep your functions small

Uncle Bob đã từng nói:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Nguyên tắc đầu tiên của các hàm là chúng nên nhỏ gọn. Nguyên tắc thứ hai là chúng nên nhỏ hơn nữa.

Một hàm nên làm một việc và làm tốt việc đó. Nhưng kích thước lý tưởng của một hàm là bao nhiêu? Không có quy tắc cứng nhắc cho điều này. Đôi khi 5 dòng là vừa đủ, có khi cần 50 dòng để đảm bảo một trách nhiệm duy nhất.

Điều tốt nhất là luôn sử dụng sự phán đoán của bạn dựa trên ngữ cảnh. Hãy thực dụng, đừng cứng nhắc. Mẹo là cố gắng viết các hàm nhỏ nhưng tránh tạo ra quá nhiều hàm đến mức gây rối cho code của bạn.

2. Name your functions well

Không có tuần nào mà tôi không gặp vấn đề các function được đặt tên kém chất lượng. Trái ngược với suy nghĩ phổ biến rằng đặt tên cho function không khó. Nó đòi hỏi rất nhiều sự nỗ lực, vài lần thử nghiệm, và sự tinh chỉnh liên tục.

Dưới đây là 4 mẹo tôi sử dụng để đặt tên cho các hàm của mình:

  • Sử dụng tên tiết lộ ý định liên quan đến lĩnh vực kinh doanh. Hãy nhớ rằng, nếu code của bạn không nói bằng ngôn ngữ của khách hàng, bạn không tập trung vào vấn đề của họ.
  • Sử dụng động từ và cụm động từ. Việc sử dụng danh từ hoặc tính từ cho tên function có thể gây vấn đề vì chúng không thể hiện rõ ràng chức năng.
  • Sử dụng quy ước đặt tên trong nhóm của bạn.
  • Đừng sử dụng các thuật ngữ khác nhau cho cùng một khái niệm. Điều đó làm cho code của bạn không nhất quán, gây nhầm lẫn cho bạn và đồng nghiệp. Thay vào đó, chỉ sử dụng một từ cho mỗi khái niệm.

3. Limit the number of parameters

Số lượng đối số lý tưởng cho một hàm là 0. Vấn đề với các hàm có quá nhiều tham số là làm tăng độ phức tạp và khiến hàm khó kiểm thử hơn.

Hãy cố gắng giới hạn tối đa 3 tham số cho mỗi hàm. Một giải pháp tuyệt vời cho vấn đề này là nhóm các tham số liên quan lại với nhau.

4. Reduce nesting with a return early

Tránh sử dụng các câu lệnh IF lồng nhau trong một hàm. Chúng làm tăng độ phức tạp và giảm tính duy trì.

Thay vào đó, hãy đảo ngược các điều kiện và sử dụng các điều kiện bảo vệ (guard clauses). Điều này sẽ giúp mã của bạn dễ theo dõi hơn. Thêm vào đó, bạn sẽ loại bỏ được các câu lệnh ELSE.

5. Write pure function with no side effects

Pure function là gì? Một hàm được gọi là pure function nếu nó luôn output giống nhau khi input giống nhau. Thứ hai, nó không có tác động phụ (side effects). Nói cách khác, đầu ra chỉ phụ thuộc vào đầu vào mà không có các hành vi ẩn.

Có 3 lợi ích của các pure function:

  • Mã nguồn trở nên dễ dự đoán hơn.
  • Chúng dễ kiểm thử hơn.
  • Chúng ta có thể chạy chúng song song.

Bạn biết rằng bạn đang làm việc với clean code khi mọi hàm bạn đọc đều làm chính xác những gì bạn mong đợi. Các pure function làm cho code của bạn trở nên clean hơn.

6. Avoid boolean flag parameters

Việc sử dụng các biến kiểu boolean làm tham số thường dẫn đến mã nguồn khó hiểu. Có hai vấn đề chính với điều này.

  • Thứ nhất, khi gọi một hàm với cờ true hoặc false, không rõ giá trị đó có ý nghĩa gì.
  • Thứ hai, rất khó để mở rộng hành vi liên quan đến các cờ đó.

Bây giờ, hãy cho tôi biết, sự khác biệt giữa hai cuộc gọi hàm sau là gì?

Và giờ hãy cho tôi biết, sự khác biệt giữa hai cuộc gọi hàm này là gì?

Thay vì sử dụng boolean, hãy sử dụng Enums để làm cho code của bạn dễ hiểu hơn. Thay đổi nhỏ, tác động lớn.

7. Use comments sparingly

Khi một hàm trở nên khó hiểu, đừng cố gắng cải thiện nó bằng cách thêm comments. Comments là một trong những dấu hiệu mã nguồn kém:

  • Chúng dễ bị lỗi thời.
  • Chúng thường thừa thãi.
  • Nếu được sử dụng nhiều, không ai đọc chúng.

Comments là công cụ tốt để giải thích WHY, nhưng chúng nên là phương án cuối cùng để giải thích WHAT. Trong hầu hết các trường hợp, bạn có thể thay thế comments bằng cách sử dụng các tên hàm phù hợp. Đừng quên: Một tên hàm mô tả dài là tốt hơn một comment mô tả dài.

Summary

Chúng ta dành gấp 10 lần thời gian để đọc mã nguồn so với việc viết mã. Việc viết các clean functions là một trong những cách mạnh mẽ nhất để tạo ra mã nguồn dễ đọc.

Hãy nhớ rằng: Lập trình không chỉ là nói cho máy tính biết phải làm gì. Đó là nói cho một lập trình viên khác biết bạn muốn máy tính làm gì.

Mỗi dòng mã bạn viết là một thông điệp gửi đến các đồng nghiệp của bạn. Hãy làm cho nó rõ ràng, ngắn gọn và thuyết phục.


Tham khảo: https://craftbettersoftware.com/p/clean-code-7-tips-to-write-clean

Bình luận

Bài viết tương tự

- vừa được xem lúc

Học Regular Expression và cuộc đời bạn sẽ bớt khổ (Updated v2.2)

. Regular Expression (RegEx) à? Nghe quen quen. . Bạn cần xử lý validate (kiểm tra tính hợp lệ) các trường dữ liệu nhập vào ô Text. .

0 0 108

- vừa được xem lúc

Naming rules - Các quy tắc vàng trong làng đặt tên

. . Đã bao giờ bạn gặp khó khăn khi phải suy nghĩ nên đặt tên biến/hàm như thế nào trong lúc code.

0 0 34

- vừa được xem lúc

Tóm tắt cuốn Clean Code của Uncle Bob

Bài viết được dịch từ Gist của wojteklu. . Quy tắc chung. .

0 0 103

- vừa được xem lúc

Tôi đi học code - lớp mẫu giáo

Chào mừng các bạn quay trở lại với blog duthaho.com.

0 0 60

- vừa được xem lúc

Lean Code CSS

Khi thiết kế và phát triển web, đôi lúc chúng ta gặp khó khăn trong việc tổ chức và quản lý code CSS. Nhiều nhà thiết kế website nghĩ rằng việc tổ chức và quản lý code thật là rắc rối, tuy nhiên nếu b

0 0 32

- vừa được xem lúc

Design Patterns là gì? Tại sao nó lại là trợ thủ đắc lực của Developers

Design Pattern là một giải pháp chung để giải quyết các vấn đề phổ biến khi thiết kế phần mềm trong lập trình hướng đối tượng OOP. Design pattern là các giải pháp tổng thể đã được tối ưu hóa, được tái

0 0 60