Độ dài lý tưởng của một phương pháp cho bạn là gì? [đóng cửa]

Trong lập trình hướng đối tượng, tất nhiên không có quy tắc chính xác nào về độ dài tối đa của một phương thức, nhưng tôi vẫn thấy hai trích dẫn này hơi mâu thuẫn với nhau, vì vậy tôi muốn nghe bạn nghĩ gì.

Trong mã sạch: Cẩm nang về nghề thủ công phần mềm linh hoạt , Robert Martin nói:

Nguyên tắc đầu tiên của chức năng là chúng phải nhỏ. Quy tắc thứ hai của các chức năng là chúng phải nhỏ hơn thế. Các chức năng không được dài 100 dòng. Các chức năng hầu như không bao giờ dài 20 dòng.

và anh ta đưa ra một ví dụ từ mã Java mà anh ta thấy từ Kent Beck:

Mỗi chức năng trong chương trình của ông chỉ dài hai, hoặc ba hoặc bốn dòng. Mỗi cái đều rõ ràng. Mỗi người kể một câu chuyện. Và từng dẫn bạn đến tiếp theo theo thứ tự hấp dẫn. Đó là cách chức năng của bạn nên ngắn!

Điều này nghe có vẻ hay, nhưng mặt khác, trong Code Complete , Steve McConnell lại nói một điều rất khác:

Thói quen nên được cho phép phát triển hữu cơ lên ​​tới 100-200 dòng, hàng thập kỷ bằng chứng nói rằng các thói quen có độ dài như vậy không có nhiều lỗi dễ xảy ra sau đó là các thói quen ngắn hơn.

Và ông đưa ra một tài liệu tham khảo cho một nghiên cứu nói rằng thói quen 65 dòng hoặc dài là rẻ hơn để phát triển.

Vì vậy, trong khi có những ý kiến ​​khác nhau về vấn đề này, có một thực hành chức năng tốt nhất cho bạn?

Các hàm thường phải ngắn, giữa 5-15 dòng là "quy tắc ngón tay cái" cá nhân của tôi khi mã hóa bằng Java hoặc C #. Đây là một kích thước tốt vì nhiều lý do:

• Nó phù hợp dễ dàng trên màn hình của bạn mà không cần cuộn
• Đó là về kích thước khái niệm mà bạn có thể giữ trong đầu
• Nó đủ ý nghĩa để yêu cầu một chức năng theo đúng nghĩa của nó (như một đoạn logic độc lập, có ý nghĩa)
• Hàm nhỏ hơn 5 dòng là một gợi ý rằng có lẽ bạn đang phá mã quá nhiều (điều này khiến bạn khó đọc / hiểu hơn nếu bạn cần điều hướng giữa các hàm). Hoặc là hoặc bạn đang quên các trường hợp đặc biệt / xử lý lỗi của bạn!

Nhưng tôi không nghĩ sẽ hữu ích khi đặt quy tắc tuyệt đối, vì sẽ luôn có ngoại lệ / lý do hợp lệ để phân kỳ khỏi quy tắc:

• Hàm truy cập một dòng thực hiện phân loại kiểu rõ ràng có thể chấp nhận được trong một số trường hợp.
• Có một số chức năng rất ngắn nhưng hữu ích (ví dụ: trao đổi như người dùng chưa biết) rõ ràng cần ít hơn 5 dòng. Không phải là vấn đề lớn, một vài hàm 3 dòng không gây hại cho cơ sở mã của bạn.
• Hàm 100 dòng là một câu lệnh chuyển đổi lớn duy nhất có thể được chấp nhận nếu nó cực kỳ rõ ràng những gì đang được thực hiện. Mã này có thể rất đơn giản về mặt khái niệm ngay cả khi nó đòi hỏi nhiều dòng để mô tả các trường hợp khác nhau. Đôi khi có ý kiến ​​cho rằng điều này nên được tái cấu trúc thành các lớp riêng biệt và được triển khai bằng cách sử dụng tính kế thừa / đa hình nhưng IMHO điều này đang đưa OOP đi quá xa - tôi chỉ muốn có một câu lệnh chuyển đổi 40 chiều lớn hơn 40 lớp mới để xử lý, ngoài ra đến một câu lệnh chuyển đổi 40 chiều để tạo ra chúng.
• Một hàm phức tạp có thể có rất nhiều biến trạng thái sẽ rất lộn xộn nếu được chuyển giữa các hàm khác nhau làm tham số. Trong trường hợp này, bạn có thể đưa ra một lập luận hợp lý rằng mã đơn giản và dễ theo dõi hơn nếu bạn giữ mọi thứ trong một hàm lớn duy nhất (mặc dù như Mark chỉ ra một cách đúng đắn, đây cũng có thể là một ứng cử viên để biến thành một lớp để gói gọn cả logic và nhà nước).
• Đôi khi các chức năng nhỏ hơn hoặc lớn hơn có lợi thế về hiệu suất (có lẽ vì lý do nội tuyến hoặc JIT như Frank đề cập). Điều này phụ thuộc rất nhiều vào việc thực hiện, nhưng nó có thể tạo ra sự khác biệt - đảm bảo bạn đạt điểm chuẩn!

Vì vậy, về cơ bản, hãy sử dụng thông thường , tuân theo các kích thước chức năng nhỏ trong hầu hết các trường hợp nhưng đừng giáo điều về nó nếu bạn có lý do thực sự tốt để thực hiện một chức năng lớn bất thường.

Mặc dù tôi đồng ý với ý kiến ​​của người khác khi họ nói rằng không có quy tắc cứng nào về số LỘC phải, tôi cá là nếu chúng ta nhìn lại các dự án mà chúng ta đã xem trong quá khứ và xác định mọi chức năng ở trên, hãy nói 150 dòng mã, tôi ' Tôi đoán chúng ta sẽ đi đến thống nhất rằng 9 trong số 10 chức năng đó phá vỡ SRP (và rất có thể là OCP), có quá nhiều biến cục bộ, quá nhiều luồng điều khiển và thường khó đọc và duy trì.

Vì vậy, trong khi LỘC có thể không phải là một chỉ báo trực tiếp về mã xấu, thì chắc chắn đó là một chỉ báo gián tiếp đàng hoàng rằng chức năng nhất định có thể được viết tốt hơn.

Trong đội của tôi, tôi rơi vào vị trí dẫn đầu và vì bất kỳ lý do gì, mọi người dường như đang lắng nghe tôi. Những gì tôi thường giải quyết là nói với nhóm rằng trong khi không có giới hạn tuyệt đối, thì bất kỳ chức năng nào, hơn 50 dòng mã sẽ tối thiểu giơ cờ đỏ trong quá trình xem xét mã, để chúng tôi xem xét lại và đánh giá lại nó cho sự phức tạp và vi phạm SRP / OCP. Sau cái nhìn thứ hai đó, chúng ta có thể để nó một mình hoặc chúng ta có thể thay đổi nó, nhưng ít nhất nó khiến mọi người nghĩ về những điều này.

Tôi bước vào một dự án mà không quan tâm đến các hướng dẫn mã hóa. Khi tôi nhìn vào mã, đôi khi tôi thấy các lớp có hơn 6000 dòng mã và ít hơn 10 phương thức. Đây là một kịch bản kinh dị khi bạn phải sửa lỗi.

Một quy tắc chung về mức độ lớn nhất của một phương pháp đôi khi không tốt lắm. Tôi thích quy tắc của Robert C. Martin (Chú Bob): "Phương pháp nên nhỏ, nhỏ hơn nhỏ". Tôi cố gắng sử dụng quy tắc này mọi lúc. Tôi đang cố gắng giữ cho các phương thức của mình đơn giản và nhỏ bằng cách làm rõ rằng phương thức của tôi chỉ làm một việc và không có gì hơn.

Nó không phải là về số lượng dòng, nó là về SRP. Theo nguyên tắc này, phương pháp của bạn nên làm một và chỉ một điều.

Nếu phương thức của bạn thực hiện điều này VÀ điều này VÀ điều này HOẶC điều đó => thì có lẽ nó đang làm rất nhiều. Hãy thử xem phương pháp này và phân tích: "ở đây tôi lấy dữ liệu này, sắp xếp nó và lấy các yếu tố tôi cần" và "ở đây tôi xử lý các yếu tố này" và "ở đây cuối cùng tôi đã kết hợp chúng để có kết quả". Các "khối" này nên được cấu trúc lại thành các phương thức khác.

Nếu bạn chỉ cần làm theo SRP, hầu hết phương pháp của bạn sẽ nhỏ và có ý định rõ ràng.

Thật không đúng khi nói "phương pháp này là> 20 dòng nên nó sai". Nó có thể là một dấu hiệu cho thấy một cái gì đó có thể sai với phương pháp này, không còn nữa.

Bạn có thể có một chuyển đổi 400 dòng trong một phương thức (thường xảy ra trong viễn thông), và nó vẫn là trách nhiệm duy nhất và nó hoàn toàn ổn.

Nó phụ thuộc , nghiêm túc, có thực sự không phải là một câu trả lời chắc chắn cho câu hỏi này bởi vì ngôn ngữ mà bạn đang làm việc với các vấn đề, năm đến mười lăm dòng đề cập trong câu trả lời này có thể làm việc cho C # hoặc Java, nhưng bằng các ngôn ngữ khác, nó không cung cấp cho bạn làm việc nhiều Tương tự, tùy thuộc vào tên miền bạn đang làm việc, bạn có thể thấy mình viết các giá trị cài đặt mã trong một cấu trúc dữ liệu lớn. Với một số cấu trúc dữ liệu, bạn có thể có hàng chục phần tử mà bạn cần đặt, bạn có nên tách mọi thứ ra để tách các chức năng chỉ vì chức năng của bạn đang chạy dài?

Như những người khác đã lưu ý, quy tắc tốt nhất là một hàm phải là một thực thể logic duy nhất xử lý một tác vụ. Nếu bạn cố gắng thực thi các quy tắc hà khắc nói rằng các hàm không thể dài hơn n dòng và bạn làm cho giá trị đó quá nhỏ, mã của bạn sẽ khó đọc hơn khi các nhà phát triển thử và sử dụng các thủ thuật ưa thích để vượt qua quy tắc. Tương tự như vậy, nếu bạn đặt nó quá cao, nó sẽ không thành vấn đề và có thể dẫn đến mã xấu mặc dù sự lười biếng. Đặt cược tốt nhất của bạn là chỉ cần tiến hành đánh giá mã để đảm bảo rằng các chức năng đang xử lý một nhiệm vụ duy nhất và để nó ở đó.

Tôi nghĩ một vấn đề ở đây là độ dài của hàm không nói gì về độ phức tạp của nó. LỘC (Dòng mã) là một công cụ xấu để đo lường bất cứ điều gì.

Một phương thức không nên quá phức tạp, nhưng có những kịch bản trong đó một phương thức dài có thể dễ dàng duy trì. Lưu ý rằng ví dụ sau không nói rằng nó không thể được chia thành các phương thức, chỉ là các phương thức sẽ không thay đổi khả năng bảo trì.

ví dụ, một trình xử lý cho dữ liệu đến có thể có một câu lệnh chuyển đổi lớn và sau đó là mã đơn giản cho mỗi trường hợp. Tôi có mã như vậy - quản lý dữ liệu đến từ nguồn cấp dữ liệu. 70 (!) Trình xử lý mã hóa số. Bây giờ, người ta sẽ nói "sử dụng hằng" - có, ngoại trừ API không cung cấp cho họ và tôi muốn ở gần "nguồn" ở đây. Phương pháp nào? Chắc chắn - thật đáng buồn khi tất cả chúng đều xử lý dữ liệu từ cùng 2 cấu trúc khổng lồ. Không có lợi trong việc tách chúng ra trừ khi có thể có nhiều phương thức hơn (khả năng đọc). Mã về bản chất không phức tạp - một chuyển đổi, tùy thuộc vào một lĩnh vực. Sau đó, mọi trường hợp có một khối phân tích x các yếu tố của dữ liệu và xuất bản chúng. Không có ác mộng bảo trì. Có một điều lặp lại "nếu điều kiện xác định liệu một trường có dữ liệu hay không (pField = pFields [x], nếu pField-> Isset () {blabla}) - tương tự khá nhiều cho mọi trường ..

Thay thế bằng một thói quen nhỏ hơn nhiều có chứa vòng lặp lồng nhau và rất nhiều câu lệnh chuyển đổi thực sự và một phương thức lớn có thể dễ dàng duy trì hơn một vòng lặp nhỏ hơn.

Vì vậy, xin lỗi, LỘC không phải là một phép đo tốt để bắt đầu. Nếu bất cứ điều gì, thì nên sử dụng điểm phức tạp / quyết định.

Tôi sẽ chỉ đưa vào một trích dẫn khác.

Các chương trình phải được viết để mọi người đọc và chỉ tình cờ để máy thực thi

- Harold Abelson

Rất có khả năng các chức năng tăng lên 100-200 tuân theo quy tắc này

Tôi đã ở trong cây vợt điên rồ này, bằng cách này hay cách khác, kể từ năm 1970.

Trong tất cả thời gian đó, với hai ngoại lệ mà tôi sẽ gặp phải trong một khoảnh khắc, tôi KHÔNG BAO GIỜ thấy một "thói quen" được thiết kế tốt (phương thức, thủ tục, chức năng, chương trình con, bất cứ điều gì) CẦN phải nhiều hơn một trang in ( dài khoảng 60 dòng). Phần lớn trong số chúng khá ngắn, theo thứ tự 10-20 dòng.

Tuy nhiên, tôi đã thấy RẤT NHIỀU mã "dòng ý thức", được viết bởi những người dường như chưa bao giờ nghe nói về mô đun hóa.

Hai trường hợp ngoại lệ là rất nhiều trường hợp đặc biệt. Một thực sự là một lớp các trường hợp ngoại lệ, mà tôi gộp lại: automata trạng thái hữu hạn lớn, được triển khai như các câu lệnh chuyển đổi xấu xí lớn, thường là do không có cách nào sạch hơn để thực hiện chúng. Những thứ này thường xuất hiện trong thiết bị kiểm tra tự động, phân tích nhật ký dữ liệu từ thiết bị được kiểm tra.

Cái còn lại là thói quen ngư lôi photon từ trò chơi STARTRK Matuszek-Reynolds-McGehearty-Cohen, được viết trong CDC 6600 FORTRAN IV. Nó phải phân tích dòng lệnh, sau đó mô phỏng chuyến bay của từng ngư lôi, với sự nhiễu loạn, kiểm tra sự tương tác giữa ngư lôi và từng loại nó có thể đánh trúng, và bằng cách mô phỏng đệ quy để thực hiện kết nối 8 chiều trên các chuỗi novae từ ngư lôi một ngôi sao bên cạnh những ngôi sao khác.

Nếu tôi tìm thấy phương pháp dài, tôi có thể đặt cược phương pháp này không được kiểm tra đơn vị đúng cách hoặc hầu hết thời gian nó không kiểm tra đơn vị. Nếu bạn bắt đầu thực hiện TDD, bạn sẽ không bao giờ xây dựng các phương thức 100 dòng với 25 trách nhiệm khác nhau và 5 vòng lặp lồng nhau. Các xét nghiệm bắt buộc bạn phải liên tục cấu trúc lại mớ hỗn độn của mình và viết mã sạch của chú Bob.

Không có quy tắc tuyệt đối về độ dài của phương thức, nhưng các quy tắc sau đây rất hữu ích:

1. Mục đích chính của chức năng là tìm giá trị trả về. Không có lý do khác cho sự tồn tại của nó. Khi lý do đó đã được điền đầy đủ, không có mã nào khác được chèn vào nó. Điều này nhất thiết phải giữ chức năng nhỏ. Gọi các chức năng khác chỉ nên được thực hiện nếu nó làm cho việc tìm giá trị trả về dễ dàng hơn.
2. Mặt khác, giao diện nên nhỏ. Điều này có nghĩa là bạn có số lượng lớn các lớp hoặc bạn có các hàm lớn - một trong hai lớp sẽ xảy ra khi bạn bắt đầu có đủ mã để làm bất cứ điều gì quan trọng. Các chương trình lớn có thể có cả hai.

Các tác giả có cùng ý nghĩa với "chức năng" và "thói quen" không? Thông thường khi tôi nói "hàm" Tôi có nghĩa là một chương trình con / hoạt động trả về một giá trị và "thủ tục" cho một lệnh không (và cuộc gọi của ai trở thành một câu lệnh đơn). Đây không phải là một sự phân biệt phổ biến trong suốt SE trong thế giới thực nhưng tôi đã thấy nó trong các văn bản người dùng.

Dù bằng cách nào, không có câu trả lời đúng cho điều này. Ưu tiên cho cái này hay cái khác (nếu có một ưu tiên nào đó) là điều tôi mong đợi sẽ rất khác nhau giữa các ngôn ngữ, dự án và tổ chức; giống như nó là với tất cả các quy ước mã.

Một điều tôi muốn nói thêm là toàn bộ "các hoạt động dài không dễ bị lỗi hơn các hoạt động ngắn" là không đúng hoàn toàn. Ngoài thực tế là nhiều mã tương đương với không gian lỗi tiềm năng hơn, rõ ràng là việc phá mã thành các phân đoạn sẽ làm cho các lỗi vừa dễ tránh vừa dễ xác định hơn. Nếu không, sẽ không có lý do gì để chia mã thành từng mảnh, lưu lại sự lặp lại. Nhưng điều này có lẽ chỉ đúng nếu các phân đoạn nói được ghi lại đủ tốt để bạn có thể xác định kết quả của một cuộc gọi hoạt động mà không cần đọc qua hoặc truy tìm mã thực tế (thiết kế theo hợp đồng dựa trên thông số kỹ thuật thay vì phụ thuộc cụ thể giữa các khu vực của mã).

Ngoài ra, nếu bạn muốn các hoạt động dài hơn hoạt động tốt, bạn có thể muốn áp dụng các quy ước mã chặt chẽ hơn để hỗ trợ chúng. Việc đưa ra một tuyên bố trả lại ở giữa một hoạt động có thể tốt cho một hoạt động ngắn, nhưng trong các hoạt động dài hơn, điều này có thể tạo ra một phần lớn mã có điều kiện nhưng rõ ràng không có điều kiện trên một lần đọc nhanh (chỉ cho một ví dụ).

Vì vậy, tôi sẽ nghĩ rằng phong cách nào ít có khả năng là cơn ác mộng đầy lỗi sẽ phụ thuộc phần lớn vào những quy ước mà bạn tuân thủ trong phần còn lại của mã. :)

IMHO, bạn không cần phải sử dụng thanh cuộn để đọc chức năng của mình. Ngay khi bạn cần di chuyển thanh cuộn, phải mất thêm một ít thời gian để hiểu chức năng hoạt động như thế nào.

Theo đó, nó phụ thuộc vào môi trường lập trình thông thường của công việc nhóm của bạn (độ phân giải màn hình, trình chỉnh sửa, kích thước phông chữ, v.v ...). Trong những năm 80, nó là 25 dòng và 80 cột. Bây giờ, trên trình chỉnh sửa của tôi, tôi hiển thị gần 50 dòng. Số cột tôi hiển thị không thay đổi kể từ khi tôi chia đôi màn hình của mình để hiển thị hai tệp.

Tóm lại, nó phụ thuộc vào việc thiết lập đồng nghiệp của bạn.

Tôi nghĩ rằng câu trả lời của TomTom gần với cách tôi cảm nhận về nó.

Càng ngày tôi càng thấy mình phức tạp theo chu kỳ hơn là các dòng.

Tôi thường nhắm đến không quá một cấu trúc điều khiển cho mỗi phương thức, ngoại trừ nhiều vòng lặp cần có để xử lý một mảng nhiều chiều.

Đôi khi tôi thấy mình đặt ifs một dòng trong các trường hợp chuyển đổi bởi vì một số lý do, đây có thể là những trường hợp tách nó ra gây cản trở hơn là giúp đỡ.

Lưu ý rằng tôi không tính logic bảo vệ chống lại giới hạn này.

Trong OOP tất cả các đối tượng và có các tính năng sau:

1. Đa hình
2. Trừu tượng
3. Di sản

Khi bạn tuân thủ các quy tắc này thì các phương thức của bạn thường nhỏ nhưng không tồn tại bất kỳ quy tắc nào cho quy tắc nhỏ hoặc rất nhỏ (ví dụ 2-3 dòng). Lợi ích của phương thức nhỏ (đơn vị nhỏ, ví dụ phương thức hoặc hàm) là:

1. dễ đọc hơn
2. duy trì tốt hơn
3. sửa lỗi tốt hơn
4. thay đổi tốt hơn