Hướng dẫn mã hóa: Các phương thức không nên chứa nhiều hơn 7 câu lệnh?

Tôi đã xem qua Nguyên tắc mã hóa AvSol cho C # và tôi đồng ý với hầu hết mọi thứ nhưng tôi thực sự tò mò muốn xem người khác nghĩ gì về một quy tắc cụ thể.

AV1500

Các phương thức không được vượt quá 7 câu lệnh Một phương thức yêu cầu nhiều hơn 7 câu lệnh đang làm quá nhiều hoặc có quá nhiều trách nhiệm. Nó cũng đòi hỏi trí óc của con người để phân tích các tuyên bố chính xác để hiểu những gì mã đang làm. Chia nó thành nhiều phương pháp nhỏ và tập trung với tên tự giải thích.

Có phải hầu hết các bạn tuân theo quy tắc này? Ngay cả khi có rất ít được lưu từ việc tạo một phương thức mới (Mã của bạn vẫn DRY ) ngoài khả năng đọc tăng lên đáng kể? Và số của bạn vẫn còn thấp đến 7? Tôi sẽ có xu hướng nhiều hơn về 10.

Tôi không nói rằng tôi vi phạm quy tắc này ở mọi nơi - ngược lại, các phương pháp của tôi nhỏ và tập trung 95% nhưng nói rằng bạn không bao giờ nên vi phạm quy tắc này thực sự đã thổi bay tôi.

Tôi thực sự chỉ muốn biết mọi người nghĩ gì về KHÔNG BAO GIỜ vi phạm quy tắc này (Đó là '1' trên tiêu chuẩn mã hóa - nghĩa là KHÔNG BAO GIỜ làm điều này). Nhưng tôi nghĩ bạn sẽ gặp khó khăn khi tìm một cơ sở mã không.

Đây là một "mùi tiêu chuẩn" với tôi. Bất cứ khi nào tôi thấy các tiêu chuẩn mã hóa với các giới hạn cụ thể trong đó, tôi lo lắng. Bạn hầu như luôn gặp phải trường hợp một phương thức cần phải lớn hơn tiêu chuẩn cho phép (cho dù đó là độ dài / số dòng, số biến, số điểm thoát, v.v.). Các tiêu chuẩn nên giống như hướng dẫn và cho phép đủ thời gian để thực hiện phán đoán tốt. Đừng hiểu sai ý tôi, thật tốt khi có các tiêu chuẩn, nhưng chúng không nên trở thành "quản lý vi mô bằng proxy".

Nó thường là một ý tưởng tốt để chia công cụ thành các phương pháp nhỏ. Nhưng điều quan trọng là phân chia những thứ có ý nghĩa.

Nếu nó không có ý nghĩa để phân chia, thì đừng phân chia. Đây thường là trường hợp đối với một số thủ tục hoặc mã GUI.

Steve McConnell đã nêu trong Code Complete rằng bạn không phải lúc nào cũng năng suất hơn khi sử dụng các phương pháp ngắn. Nếu bạn phân tách khi nó không có ý nghĩa, bạn thêm độ phức tạp vào mã không có lợi.

Như mọi khi với hướng dẫn, thật tốt để nhớ tại sao các ràng buộc tồn tại, vì vậy bạn có thể tìm hiểu khi nó không áp dụng. Trong hầu hết các mã, các phương thức sẽ ngắn hoặc bạn có thể gặp vấn đề với DRY hoặc tách các mối quan tâm . Nhưng nếu không phải vậy, thì tốt thôi.

Nó nên được coi là một quy tắc của ngón tay cái.

Những thứ như "Không quá 80 (100.120) cột văn bản", "một điểm thoát cho mỗi phương thức", "không quá 2 cấp độ lồng", là những gì tôi sẽ gọi là ngưỡng cho các chỉ số về mùi mã. Nếu bạn vi phạm chúng đôi khi, điều đó không nhất thiết có nghĩa là mã xấu. Nếu bạn thấy mình vi phạm chúng một cách nhất quán thì có gì đó có mùi trong mã và bạn có thể muốn tạm dừng và suy nghĩ lại về cách tiếp cận của mình.

Đối với tôi, các tiêu chí quan trọng nhất là "Mã này có dễ hiểu không?", "Nó có lặp đi lặp lại không?", "Nó có bị phá vỡ ở những nơi hợp lý không?", "Nó có được ghép lỏng lẻo không?" Có một vài điều nữa, nhưng tôi nghĩ rằng ý tưởng cơ bản có thể được tóm tắt bằng cách ghi nhớ lời khuyên của Donald Knuth: "Các chương trình được con người đọc và chỉ tình cờ cho máy tính thực thi."

Tôi chưa bao giờ dành thời gian để thực sự đếm số lượng câu lệnh trong các phương thức của mình, nhưng tôi cố gắng viết các phương thức thực hiện sạch sẽ một mục đích rõ ràng. Miễn là mã của bạn sạch sẽ, có thể đọc được và tuân theo các nguyên tắc DRY và Trách nhiệm duy nhất , có lẽ bạn đã hoàn thành công việc của mình. Tôi nghĩ rằng việc phân tách một phương thức một cách tùy tiện chỉ để thực thi giới hạn bảy câu lệnh có thể làm cho mã của bạn không thể đọc / duy trì được.

Nó gần đúng

Những loại quy tắc không nên được thực hiện quá theo nghĩa đen. Họ có thể đã nói " phương pháp nên ngắn ". Tuy nhiên, một số người sẽ hiểu rằng "ít nhất 1 trang" và những người khác là "tối đa 2 dòng".

Tôi cho rằng họ đã nói "7 tuyên bố" để cho bạn một ý tưởng sơ bộ (mặc dù tôi nghĩ họ nên nói "khoảng 7"). Nếu bạn cần 9 lần một lần, đừng đổ mồ hôi. Nhưng nếu bạn đạt 20, bạn sẽ biết bạn không ở đúng sân bóng cho quy tắc này.

7 là một con số hoàn toàn tùy ý, hoàn toàn không có ý nghĩa.

Độ phức tạp theo chu kỳ là một vấn đề lớn hơn số lượng báo cáo. Tôi đã thấy mã có 100 câu lệnh trong một phương thức (mà tôi nghĩ là khủng khiếp), nhưng nó có độ phức tạp theo chu kỳ là 1 và nó thực sự chỉ làm được 1 điều. Chỉ có rất nhiều bước. Chúng tôi đã thảo luận tách nó thành các phương thức nhỏ hơn, nhưng các phương thức đó sẽ chỉ được gọi bằng phương thức này.

Trong khi đó là một trường hợp khá cực đoan, vấn đề là bạn cần giữ mã DRY và độ phức tạp chu kỳ thấp. Điều đó quan trọng hơn số lượng dòng trong một phương thức.

Lấy một tuyên bố chuyển đổi / trường hợp ví dụ. Nếu bạn có nhiều hơn 7 giá trị có thể, bạn có cần chia đánh giá thành nhiều phương thức không? Tất nhiên là không, điều đó sẽ thật ngớ ngẩn.

Việc giả mạo mã thành nhiều phương thức hơn chỉ để giữ số lượng câu lệnh dưới 7 chỉ làm cho mã của bạn tệ hơn.

Hướng dẫn nên là Mỗi phương thức nên làm 1 điều và giữ mã DRY của bạn.

Vâng, nó phụ thuộc một chút. Tôi viết rất nhiều mã truy cập cơ sở dữ liệu. Mã tấm nồi hơi để xử lý ngoại lệ là nhiều hơn bảy câu lệnh trong rất nhiều trường hợp. Tôi muốn nói rằng hướng dẫn tốt nhất là đảm bảo chức năng của bạn có một mục đích

Tất cả mọi thứ là một sự đánh đổi. Vấn đề với cách tiếp cận được đề xuất - tái cấu trúc thành một số phương thức và các lớp sao cho mỗi phương thức ngắn - là mặc dù vì những lý do khác nhau, nó dẫn đến mã không thể đọc được khi được đưa đến mức cực đoan.

Hãy tưởng tượng một phương pháp foo()làm 7 việc. Bạn có thể lập luận rằng 7 điều là quá nhiều. Có thể trong nhiều trường hợp bạn đúng. Mặt khác, 7 điều này có thể liên quan chặt chẽ với nhau; logic có thể trôi chảy và đọc như văn xuôi; bạn có thể không gặp khó khăn để hiểu nó khi bạn thực sự cần. Điều có thể tồi tệ hơn nhiều là có 7 thứ đó được phân phối trên một cây nguồn lớn, do đó nếu bạn nhìn vào foo()bạn sẽ không biết nó làm gì mà không tìm kiếm ở 7 nơi khác nhau.

Nhiều người nhận được các quy tắc như thế này trong đầu, và kết quả là những gì tôi nghĩ về spaghetti OO. Mọi thứ đều gọn gàng, được đóng hộp theo phương pháp hoặc lớp nhỏ của riêng nó, với các giao dịch vi mô nhỏ nguyên tử xảy ra ở mỗi nơi. Nhưng không thể làm mới cơ sở mã như vậy và biết nó đang làm gì. Bạn trở nên lạc lõng.

Đó không phải là một hướng dẫn tồi. Tôi chưa bao giờ hối hận về việc chia nhỏ các phương thức và các lớp (tôi chưa bao giờ thấy mình có quá nhiều) miễn là chúng được nhóm lại và liên quan với nhau đủ tốt.

Mẹo nhỏ là KHÔNG chia nó theo chiều dọc (Chỉ cần ngắt một phương thức tại một điểm và bắt đầu một phương thức mới). Thủ thuật, giống như với kiểm thử đơn vị, là ghi nhớ quy tắc như vậy ngay từ đầu để bạn thực sự thiết kế tốt hơn, chuyển 3 hoặc 4 câu lệnh giữa phương thức sang phương thức khác vì có một cuộc gọi phương thức mô tả những gì bạn đang làm tốt hơn 3 hoặc 4 câu lệnh ở giữa mã của bạn.

Kiểu phân tách này, ngay cả khi nó tùy ý và chỉ được sử dụng một lần, có thể dẫn đến việc tái cấu trúc tốt hơn sau đó do sự rõ ràng mới của mã, điều này cũng đúng với các lớp nhỏ hơn.

Hãy nghĩ về nó giống như bạn sẽ thử nghiệm đơn vị. Nếu bạn cố gắng thêm kiểm thử đơn vị sau khi thực tế thì điều đó thật khó khăn và đôi khi dường như là không thể nhưng nếu bạn thiết kế nó ngay từ đầu thì nó thực sự làm cho tất cả mã của bạn tốt hơn.

Tóm lược? Nếu so sánh mùi thiết kế của "Sử dụng ít hơn 7 câu lệnh" với mùi mã của "Tôi đã sử dụng hơn 7 câu lệnh", tôi muốn loại bỏ mùi mã hơn.

Ồ Tôi không bao giờ mong đợi tìm thấy một cuộc thảo luận căng thẳng như vậy trên một hướng dẫn đơn giản mà đại khái nói rằng các phương pháp của bạn nên rất nhỏ. Bởi vì họ luôn là những nhà phát triển muốn hướng dẫn của họ rõ ràng, tôi chọn 7 vì điều đó nghe có vẻ như là một ngưỡng tốt.

Một số bạn đã trích dẫn từ chối trách nhiệm ở phần đầu của tài liệu. Nhưng để rõ ràng, tài liệu này đại diện cho một tập hợp các hướng dẫn cố gắng giúp bạn viết mã tốt hơn và thiết kế các hệ thống tốt hơn. Tôi chưa bao giờ tuyên bố rằng bất cứ điều gì nên là một quy tắc, mặc dù hướng dẫn được đánh dấu là cấp 1. Những cấp độ đó chỉ đơn giản là ý kiến ​​chung của nhiều người đã sử dụng tài liệu này trong một thời gian.

Tôi cũng chưa bao giờ tự nhận là một chuyên gia. Nhưng tôi đã làm nghề này được 15 năm rồi, với khoảng 4 năm kinh nghiệm về C ++ và 11 năm kinh nghiệm về C #. Ban đầu nó dựa trên Sức mạnh công nghiệp C ++, nhưng tôi đã tinh chỉnh nó kể từ đó với đầu vào từ cộng đồng.

Bất kể, điểm tôi đang cố gắng nêu lên là bạn nên tiếp tục suy nghĩ cho chính mình. Nếu bạn nghĩ rằng hướng dẫn 7 câu không hữu ích, thì chỉ cần làm cho nó dài hơn. Heck, tôi thậm chí thỉnh thoảng vi phạm hướng dẫn đó. Tôi chỉ vi phạm nó một cách đồng ý và chấp nhận hậu quả.

Thứ nhất: đó là một hướng dẫn, không phải là một quy tắc. Nó được gọi là hướng dẫn, vì vậy hãy coi nó như vậy. Điều này ngụ ý rằng sự phán xét của riêng bạn cũng được yêu cầu (như mọi khi)

Ngoài ra, tôi có thể nghĩ ra rất nhiều ví dụ về mã tốt không tuân thủ ràng buộc này. Mặc dù nó chỉ là một hướng dẫn, nó là một người nghèo.

Tôi đồng ý với tuyên bố trên tôi. Đây chỉ là kim chỉ nam và trong một thế giới hoàn hảo, mọi thứ sẽ là đồ vật, được tái sử dụng trong mọi chương trình và thế giới sẽ là một nơi tuyệt đẹp. Điều này không phải lúc nào cũng đúng và đôi khi điều đó sẽ dẫn đến rất nhiều tài nguyên hoặc lãng phí. Bạn cũng cần phải ghi nhớ điều đó.

Khá ngớ ngẩn khi bạn thêm xử lý ngoại lệ vào hỗn hợp.

Sau khi "thử, bắt, cuối cùng", bạn còn lại bốn câu lệnh cho mỗi phương thức!

Ngoài ra, hãy xem xét một phương thức "validateForm" cho biểu mẫu 20 trường, ngay cả khi bạn xử lý tất cả các xác nhận riêng lẻ trong các phương thức riêng biệt, bạn vẫn có 20 phương thức xác thực trường để gọi. Theo các hướng dẫn này, bạn sẽ kết thúc với một số phân chia vô nghĩa như "validateTopOfScreen", "validateMiddleOfScreen" và "validateBottomOfScreen".

Câu hỏi là kết hợp "quy tắc" với "hướng dẫn". Các quy tắc có nghĩa là phải tuân theo - hướng dẫn là lời khuyên có nghĩa là khiến bạn phải xem xét những gì bạn đang làm và nếu nó thực sự có thể được thực hiện theo cách tốt hơn.

Tôi nói, trung bình, hầu hết các chương trình có thể được cải thiện bằng cách làm theo các hướng dẫn nhưng sẽ luôn có trường hợp tuân theo các hướng dẫn một cách giáo điều sẽ gây ra nhiều vấn đề hơn so với dự định giải quyết. Đó là lý do tại sao chúng không được trình bày dưới dạng quy tắc, mà là hướng dẫn.

Một người trả lời trước đã chỉ ra rằng các tác giả của các hướng dẫn không bao giờ có ý định áp dụng chúng một cách giáo điều và bao gồm các tuyên bố về hiệu ứng đó trong tài liệu của họ.

Tôi đồng ý với soe của các ý kiến ​​trên. 7 đối với tôi là độc lập và có thể hữu ích trong một số ngôn ngữ có ruby, nhưng đối với các ngôn ngữ như C #, Java, C ++, tôi nghi ngờ quy ước "7 dòng" này. Để tôi cho bạn một ví dụ. Ứng dụng hiện tại của tôi có 22 trường văn bản và tôi xác thực phía máy chủ. Phương thức này được gọi là validateInput () và tùy chọn của tôi là xác thực tất cả các trường trong một phương thức trừ khi tôi xác thực một cái gì đó phức tạp như checkEmailFormat (). Vì vậy, về cơ bản mã phương thức validateInput của tôi là 108 dòng với các lệnh gọi thỉnh thoảng để xác thực phức tạp.

Bây giờ hãy tưởng tượng nếu tôi gọi 25 phương thức để xác nhận từng trường. Nếu một nhà phát triển mới xuất hiện, anh ta sẽ phải vào và ra khỏi phương thức chính để chuyển qua 25 phương thức mà lần lượt có thể gọi một vài phương thức khác. Anh ấy chắc chắn sẽ bị lạc trong các dự án lớn.

Những gì tôi thực sự làm để làm cho mã của tôi rõ ràng là cung cấp các nhận xét rõ ràng về cơ bản nói lên những gì 4 dòng này đang làm -

validateInput (người dùng UserObj) {

// Xác thực tên đầu tiên ....... ......

// xác thực họ ...... ......

// xác thực email ..... // quá phức tạp để kiểm tra định dạng email expresion thường xuyên checkEmailFormat (); .... .....

và v.v.

Quy tắc xấu. Với mã để xử lý ngoại lệ, thiết lập các trường cơ sở dữ liệu, xác nhận hợp lệ, làm thế nào hầu hết các phương thức có thể nằm dưới bảy câu lệnh? Chúng ta có bao giờ nên làm chức năng lambda nội tuyến?

Các dòng mã là một số lượng phức tạp tùy ý. Với các phương thức mở rộng, tôi có thể tạo mã như

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Tất cả các lập trình viên cơ sở nên bị buộc phải tuân thủ nguyên tắc này. Điều đó sẽ buộc họ phải suy nghĩ về cấu trúc của những gì họ đang bận rộn, thay vì chỉ thêm ngày càng nhiều mã dòng.

Tôi hiện đang xem xét một phương pháp gồm 550 dòng mã với rất nhiều câu lệnh if khác và tiếp tục và trả về được dệt vào nó. Đó là tào lao. Có phải lập trình viên chỉ bị buộc phải suy nghĩ về những gì anh ta đang làm ...