Có một số dòng mã tối ưu cho mỗi chức năng? [đóng cửa]

Các hàm không chỉ được sử dụng để giảm thiểu việc sao chép mã - chúng còn được sử dụng để tách một hàm dài thành các hàm nhỏ hơn để tăng khả năng đọc, cũng như làm cho mã tự nhận xét. Tuy nhiên, mức tăng này không tỷ lệ nghịch trực tiếp với số lượng LỘC trên mỗi hàm hoặc phương thức; nếu không, chúng ta sẽ có hàng tấn hàm, tất cả chỉ chứa một hoặc hai dòng mã.

Điều này khiến tôi tự hỏi: Có tồn tại số lượng LỘC tối ưu cho mỗi chức năng không? Nếu vậy, nó là gì và nó có bị lệch giữa các ngôn ngữ không?

Thay vì số dòng, tiêu chí tôi sẽ sử dụng là mỗi hàm chỉ nên làm một việc và làm tốt.

Một quy tắc ngón tay cái cũ là một chức năng phải hoàn toàn hiển thị trên màn hình, mà không cần phải cuộn.

Ý tưởng cơ bản là, nếu bạn không thể xem xét toàn bộ chức năng tại một thời điểm, chức năng này quá phức tạp và bạn nên chia nó thành nhiều phần cơ bản hơn.

Mặc dù quy tắc này rất thiết thực và hữu ích, nhưng quy tắc chính thức là bạn chỉ nên giữ một bước logic duy nhất trong một hàm. Một chức năng chỉ là một công việc cơ bản, nếu bạn có thể phân chia công việc thành nhiều phần cơ bản hơn, chức năng phải được phân chia.

Chẳng có ai.

Màn hình ngày càng lớn hơn, cỡ chữ nhỏ hơn. Quy tắc ngón tay cái không hoạt động tốt khi mọi người có ngón tay cái có kích thước khác nhau.

Ngắn gọn. Nếu chức năng của bạn làm được nhiều việc thì có lẽ nên chia nó thành những việc nhỏ hơn.

Smalltalk có một cách hơi bất thường để giảm kích thước của các phương thức. Khi bạn viết mã, bạn viết nó trong một tiện ích gọi là Trình duyệt. Trình duyệt có hai phần chính, được chia theo chiều ngang. Mã của bạn đi ở nửa dưới.

Theo mặc định, Trình duyệt không lớn lắm. Bạn có thể đặt 5 hoặc 6 dòng trước khi bắt đầu cuộn. Cuộn, tất nhiên, là hơi khó chịu.

Vì vậy, trong Smalltalk, môi trường "khuyến khích" bạn viết các phương thức ngắn, dài tối đa khoảng 6 dòng. (Điều đó thường rất nhiều; Smalltalk là một ngôn ngữ ngắn gọn.)

Số lượng dòng mã lý tưởng trong một phương thức là biến. Về cơ bản, bạn chỉ muốn viết một mã vừa đủ để làm những gì cần thực hiện trong bối cảnh định nghĩa của hàm. Tôi nghĩ rằng đây là một loại Nguyên tắc Trách nhiệm Đơn lẻ , chỉ áp dụng cho một phương thức thay vì một lớp.

Trong đó một phương thức có rất nhiều logic và một số bước cần hoàn thành, thì việc chia phương thức thành nhiều bước riêng biệt sẽ rất hợp lý. Mỗi bước này sẽ được trích xuất thành các phương thức mới theo yêu cầu.

"nếu không, chúng ta sẽ có hàng tấn hàm, tất cả chỉ chứa một hoặc hai dòng mã."

Mỗi phương thức càng ít, nó càng dễ xác định và đơn giản hơn để hiểu và quản lý. Không có gì sai khi có hàng trăm phương thức nếu bạn cần chúng. Ngoài ra, để phù hợp với SRP mà tôi đã đề cập trước đó, việc trích xuất các lớp mới trở nên dễ dàng hơn khi các phương thức đã bị trêu chọc thành các phần nhỏ hơn và dễ quản lý hơn.

Câu trả lời là tất nhiên 42 .

Điều quan trọng cần lưu ý: Không có chức năng nào có thể vi phạm SRP , hoặc bạn phải đối mặt với điều tra spanisch .

Một vài gợi ý làm thế nào để giảm lượng đạn:

• Có ý kiến ​​đánh dấu các phần riêng lẻ? Những phần đó nên là chức năng.
• Có chuỗi if-other hoặc chuyển đổi câu lệnh bên ngoài nhà máy / nhà xây dựng không? Thiết kế của bạn có thể cần một số mẫu thiết kế tốt hơn để giúp bạn phân chia trách nhiệm.
• Các chức năng của bạn có dễ kiểm tra không? Làm cho các chức năng của bạn dễ dàng để kiểm tra, chúng sẽ sụp đổ.
• Có phức tạp và chỉ không có đất trong sigth (1000 dòng quái vật)? Thực hiện tái cấu trúc phế liệu - đó là tái cấu trúc và không lưu nó với hy vọng được giáo dục về các trách nhiệm của mã.

Dưới đây là một số manh mối:

• Nếu bạn gặp khó khăn khi viết bình luận giải thích mục đích và cách sử dụng chức năng thì quá dài.

• Nếu bạn muốn viết bình luận giải thích hoạt động của một phần mã trong hàm, thì hàm đó quá dài.

• Nếu bạn đang dán mã từ một chức năng khác, thì cả hai đều quá dài (trích xuất mã đó dưới dạng một chức năng riêng biệt).

• Nếu bạn cần một quy ước mã hóa để tách các thành viên dữ liệu lớp khỏi các biến cục bộ, thì hàm này quá dài và lớp có quá nhiều thành viên.

• Nếu bạn cần ghi chú trong khi đọc một chức năng, nó quá dài.

Có 'tấn' chức năng, mỗi chức năng chỉ dài một hoặc hai dòng, không nhất thiết là điều xấu. Tôi thấy rằng những chức năng nhỏ đó đã được sử dụng lại nhiều hơn tôi dự kiến ​​ban đầu.