Một thực hành mã tốt khi nào để tạo một hàm / phương thức cho các đoạn mã lặp lại nhỏ là gì?

Nhiều lần trong suốt quá trình viết các chương trình lớn hơn, tôi đã đặt câu hỏi sau bao nhiêu bản sao và dán có ý nghĩa gì khi đặt mã vào một hàm hoặc phương thức và quy tắc tốt là gì? Tôi đã sử dụng quy tắc ngón tay cái gồm bốn dòng hoặc lớn hơn và xuất hiện nhiều hơn hai lần, sau đó tôi tạo một hàm / phương thức đơn giản chứa mã đó. Bạn có thể nghĩ về một thực hành tốt hơn hoặc cung cấp bất kỳ con trỏ? Đây là nhiều hơn một câu hỏi mẫu thiết kế chung chứ không phải là một câu hỏi cụ thể về ngôn ngữ.

Tôi sử dụng các chức năng một phần như là một cách để ghi lại mã. Gọi một hàm với một tên có ý nghĩa giúp dễ hiểu mã hơn. Trong một số trường hợp, ngay cả một hàm với một dòng duy nhất cũng có ý nghĩa.

Ví dụ, trong "Mã sạch", Robert C. Martin đưa ra ví dụ sau: Bạn muốn xem cái nào hơn? Điều này:

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65))

Hay cái này?

if (employee.isEligibleForFullBenefits())

Tôi không luôn đồng ý với anh ta, nhưng trong trường hợp này thì có. Mã phải được đọc, không chỉ khi bạn viết nó và bạn biết mọi chi tiết, mà cả lúc 9 giờ tối khi bạn phải sửa lỗi trong mã của người khác. Nhìn chằm chằm vào một điều kiện dài và cố gắng tìm ra tất cả các tiêu cực kép không được khuyến khích. Nếu bạn chỉ có thể đặt tên cho nó (không chỉ các điều kiện, mà mỗi đoạn mã bạn viết), nó sẽ trở nên đơn giản hơn rất nhiều.

Tôi chưa bao giờ hối hận khi đặt một cái gì đó vào một chức năng, và nếu bạn lo lắng về hiệu suất, thì hãy cấu hình trước.

Có một sự hiểu lầm phổ biến rằng các lệnh gọi hàm chỉ nên được thực hiện để tránh các phân đoạn mã lặp đi lặp lại. Nguyên tắc nhỏ của tôi là bất kỳ đơn vị công việc logic nào cũng phải được tạo thành một hàm, ngay cả khi nó chỉ được sử dụng ở một nơi duy nhất. Điều này thường dẫn đến khả năng đọc tốt hơn và cho phép bạn viết mã tự viết tài liệu, trong đó tên hàm thay thế các bình luận và bạn không cần phải viết thêm các bình luận giải thích những gì bạn đang làm.

Nếu nó được sử dụng trong nhiều hơn một nơi, và

• nó có khả năng thay đổi, hoặc
• thật khó để làm đúng

sau đó làm cho nó một chức năng hoặc phương thức. Theo kinh nghiệm của tôi, các đoạn mã lặp đi lặp lại sẽ tự nhiên rơi vào một trong các loại này (thường là loại đầu tiên, nhưng sau đó các danh mục trùng nhau rất nhiều;). Tất nhiên, bất cứ thứ gì phải có trong giao diện cũng là một chức năng / phương thức riêng.

Hầu như luôn luôn, đặc biệt là nếu mỗi bản sao đại diện cho cùng một hoạt động theo quan điểm khái niệm. Nếu nó được thực hiện theo cùng một cách, nhưng trên các loại khác nhau, hãy thực hiện chung.

Lý do duy nhất không làm như vậy mà tôi có thể nghĩ đến là một trong những bảo trì: đôi khi có thể thuận tiện hơn để tránh tạo ra sự phụ thuộc giữa những thứ riêng biệt, thậm chí với chi phí trùng lặp.

Tìm kiếm " tái cấu trúc " sẽ đưa bạn đến nhiều nguồn lực cho "các thực tiễn tốt nhất" trong ngành cho quy trình rất phổ biến này. Bài báo hơi nổi tiếng, Một lần và Chỉ một lần là một tài liệu tham khảo lịch sử tuyệt vời giải thích những gì một số người coi là "thực tiễn tốt nhất" cho những mối quan tâm được nêu ra bởi câu hỏi của bạn. Ngoài ra, khái niệm thậm chí còn chung hơn được gọi là Đừng lặp lại chính mình (DRY) . Để có một bộ câu trả lời thực sự sâu sắc cho câu hỏi của bạn, hãy đọc tác phẩm cổ điển tuyệt vời của Martin Fowler , Tái cấu trúc: Cải thiện Thiết kế của Mã hiện tại , bao gồm một số lời khuyên nổi tiếng nhất để tái cấu trúc , đó là những gì bạn đang cố gắng thực hiện bằng trực giác !

Nếu mã được lặp lại chính xác ở nhiều nơi và phần lặp lại sẽ không thay đổi trong tương lai gần thì tôi sẽ tách nó thành một hàm.

Điều đó phụ thuộc vào bản chất của sự gắn kết của mã lặp lại. Nếu phần mã lặp đi lặp lại đang thực hiện một chức năng cụ thể, thì đó là một ứng cử viên tuyệt vời để được tạo thành một phương thức, một phần vì nguyên tắc DRY , một phần vì nếu chức năng cần được tối ưu hóa hoặc sửa chữa, thì chỉ có một phần mã để đối phó với.

Nếu sự liên kết là ngẫu nhiên, tốt hơn là lặp lại mã hơn là biến nó thành một phương thức. Nếu bạn cần thêm một cái gì đó vào giữa một trong các chuỗi mã để đáp ứng một trong những cách sử dụng đoạn mã đó, nếu đó là trong một phương thức, thay đổi bạn thực hiện có thể ảnh hưởng đến việc sử dụng phương thức đó.

Xem bài viết Wikipedia về khái niệm gắn kết mã .

Bạn phải phân biệt giữa các hàm theo nghĩa lập trình có cấu trúc và các phương thức của một lớp.

Trong ví dụ của bạn, những gì bạn đã thể hiện là một phương thức như vậy không nên được mã hóa theo dòng.

bạn có thể phải xác thực một chuỗi để xem đó có phải là số hay không, trong trường hợp này, bạn sử dụng hàm và hầu hết các câu trả lời trước được áp dụng.

Sự khác biệt này là đặc biệt quan trọng trong các dự án lớn.

Càng nhiều càng tốt, cố gắng tách các quy tắc kinh doanh (đó là các phương thức) khỏi các thuật toán điện toán (đó là các hàm lập trình thuần túy).