Trong hai năm qua, tôi đã viết rất nhiều về các ngôn ngữ lập trình và những điều kỳ quặc của chúng—đặc biệt là Java và Python. Vì lý do gì, tôi càng viết, tôi càng học được nhiều. Khi kiến thức bắt đầu tăng lên, tôi bắt đầu tự hỏi mình một số câu hỏi sâu hơn về những gì tôi đã học được. Một trong những câu hỏi đó tình cờ là "điều gì khiến một điều gì đó trở nên tồi tệ?"
Mục lục
1 Giới thiệu
2 Nghiên cứu điển hình. Nhiều câu lệnh trả về
2. 1 Đọc
2. 2 Tóm tắt
2. 3 Phản biện
3 Phán quyết. Trả lại nhiều lần là được
Giới thiệu
Nếu bạn đã từng theo dõi, có lẽ bạn đã bắt gặp tôi sử dụng cụm từ “x được coi là thông lệ xấu”, nhưng tôi thường không có cơ sở lý luận để chứng minh cho tuyên bố đó. Đôi khi tôi sẽ cung cấp một ví dụ về một số phản tác dụng của phong cách mã hóa hoặc thậm chí tôi có thể chia sẻ một nguồn. Tuy nhiên, vào cuối ngày, tôi chỉ tuân theo các quy ước của cộng đồng
Tự nhiên, tôi cảm thấy phiền lòng vì những lời giải thích mờ nhạt của mình. Chắc chắn, các phản ví dụ đã làm rất tốt việc minh họa lý do tại sao một phương pháp cụ thể có thể bị coi là “xấu”, nhưng tôi thực sự muốn biết thêm. Bạn biết đấy, như
- Bối cảnh lịch sử đằng sau một thông lệ “xấu” là gì?
- Lập luận chống lại một thực hành “xấu” có thực sự đứng vững không?
Do đó, tôi quyết định thực hiện một nghiên cứu điển hình về một số kỹ thuật được coi là thực hành không tốt và kiểm tra chúng thật chi tiết.
nghiên cứu điển hình. Nhiều câu lệnh trả về
Để xác định điều gì làm cho một hành vi nào đó trở nên tồi tệ, tôi đã quyết định đào sâu vào một số hành vi xấu thường được chấp nhận. Mục tiêu sẽ là giải cấu trúc các lập luận của họ để cố gắng tìm ra liệu có bất kỳ bài học nào được rút ra một cách tổng thể hay không.
Để bắt đầu, tôi muốn xem xét ý tưởng rằng việc có một hàm có nhiều giá trị trả về vốn dĩ là một ý tưởng tồi. Rốt cuộc, tôi có thể đưa ra một số ví dụ mà tôi muốn có nhiều câu lệnh trả về hơn, vì vậy hãy xem liệu chúng ta có thể lần ra nguồn gốc của cách làm không tốt này không
Đọc
Để hiểu được sắc thái đằng sau vấn đề này, điều quan trọng là phải đọc nó. Sau một số tìm kiếm trên Google, tôi đã có thể tìm thấy một số bài viết về chủ đề này
- Mẹo mã hóa. Có một điểm thoát duy nhất
- Khái niệm “một lần trở lại” đến từ đâu?
- Điểm thoát chức năng đơn
- Nhập một lần, Thoát một lần, liệu nó có còn được áp dụng trong các ngôn ngữ hướng đối tượng không?
- Tại sao nhiều câu lệnh trả về là một ý tưởng tồi trong OOP
- Chiến tranh tôn giáo #48,293. đấu đơn. Trả lại nhiều lần
- Về sớm, về thường xuyên
Bản tóm tắt
Sau khi nghiên cứu sâu hơn, có vẻ như lập luận chống lại nhiều câu lệnh trả về xuất phát từ nguyên tắc “vào một lần, ra một lần” [SESE] của lập trình có cấu trúc. Theo nguyên tắc đó, một chức năng chỉ nên có một điểm vào duy nhất và một điểm thoát duy nhất. Trong trường hợp này, một điểm vào duy nhất có nghĩa là một chức năng chỉ nên được nhập từ nơi nó bắt đầu—chứ không phải một điểm tùy ý ở giữa. Trong khi đó, một điểm thoát duy nhất có nghĩa là một chức năng không được thoát đến [không phải từ] nhiều hơn một nơi
Tất nhiên, các ngôn ngữ lập trình hiện đại không nhất thiết cho phép bạn làm một trong hai điều này. Các chức năng luôn bắt đầu từ trên cùng và luôn quay lại trình gọi của chúng. Điều đó nói rằng, bằng cách nào đó, nguyên tắc SESE đã có một hình thức mới cho thấy rằng việc sử dụng nhiều hơn một câu lệnh trả về là một cách làm không tốt
Nếu bạn thực hiện một số hoạt động đào sâu, bạn sẽ thấy các lập luận trích dẫn tính dễ vỡ và khả năng bảo trì của mã. Đặc biệt, nhiều người không thích nhiều lợi nhuận vì chúng đưa ra các điểm thoát mới cần được tính đến như một phần của quy trình kiểm soát
Theo kinh nghiệm của riêng tôi, tôi đã thấy rất nhiều giáo sư nói với sinh viên tránh sử dụng nhiều câu lệnh trả về. Theo hiểu biết của tôi, lý do đằng sau một quy tắc bao trùm như thế này là để thực thi một loại kỷ luật nhằm thúc đẩy sinh viên hướng tới các phương pháp lập trình tốt hơn. Trong nhiều trường hợp, các giáo sư này đưa ra các ví dụ mà quy tắc có thể bị phá vỡ—chỉ sau khi sinh viên có đủ kinh nghiệm để xử lý các sắc thái
Đối số truy cập
Một trong những điều kỳ lạ nhất mà tôi nhận thấy về nguyên tắc lối thoát duy nhất là hầu như không có ai ủng hộ nó trên internet—ít nhất là không quá mức. Tuy nhiên, tôi vẫn thấy và nghe nó được trích dẫn đủ để cuộc tranh luận này tiếp tục sôi nổi
Dù sao đi nữa, có một số trường hợp tôi hoàn toàn sẽ sử dụng nhiều câu lệnh trả về. Đặc biệt, bất cứ khi nào tôi thực hiện tìm kiếm tuyến tính của cấu trúc dữ liệu, tôi sẽ quay lại ngay khi tìm thấy mục đó. Trả về sớm không chỉ làm giảm độ phức tạp của mã mà còn giúp giải pháp dễ đọc hơn
Ngoài ra, tôi đã nghe nói về Điều khoản bảo vệ
Tuy nhiên, có lẽ lập luận yêu thích của tôi chống lại nguyên tắc SESE phải đến từ Abby Fichtner
Nhưng điều tồi tệ nhất là nếu bạn đang đặt một giá trị và bạn chọn – ngay cả sau khi đã đặt giá trị phù hợp cho tình huống này – để tiếp tục xử lý, thì bạn có nguy cơ vô tình thay đổi giá trị từ giá trị đúng sang giá trị không chính xác.
Khi sử dụng các ngôn ngữ lập trình tận dụng lợi thế của trạng thái, việc từ chối thoát khi bạn có giải pháp là rất rủi ro. Điều đó có nghĩa là bạn có thể làm hỏng kết quả của mình do tất cả quá trình xử lý bổ sung mà bạn sẽ không phải thực hiện nếu bạn vừa thoát ra sớm
Cuối cùng, tôi nhận thấy rằng nhiều lập luận cho nguyên tắc SESE sử dụng các ví dụ phức tạp. Trong nhiều trường hợp, các ví dụ có nhiều vấn đề hơn nhiều câu lệnh trả về
Lời phán quyết. Trả lại nhiều lần là được
Sau khi xem xét bằng chứng, tôi phải nói rằng quy tắc câu lệnh trả về nhiều lần hơi lỗi thời. Trên thực tế, trường phái tư tưởng hiện đại dường như đã biến mất sớm như lập luận của Christina Burger
Như với mọi nguyên tắc phần mềm, luôn có một chút sắc thái. Tôi có xu hướng không thích các quy tắc cứng nhắc sử dụng các thuật ngữ như “luôn luôn” hoặc “không bao giờ. ” Chắc chắn, có những nơi mà một lượt trả lại là lý tưởng và những nơi khác mà nhiều lượt trả lại thì tốt hơn. Tùy thuộc vào bạn để đưa ra quyết định đó
Như đã nói, đó là tất cả những gì tôi muốn nói về chủ đề này. Nếu bạn thích bài viết này và muốn xem nhiều hơn nữa, hãy cho tôi biết. Ngoài ra, bạn có thể xem một số bài viết liên quan này
- Ngừng sử dụng cờ để kiểm soát vòng lặp của bạn
- Cải thiện khả năng đọc mã bằng cách sử dụng chế độ tham số
- Số ma thuật là gì và chúng tôi khắc phục nó như thế nào?
Tương tự như vậy, bạn luôn được chào đón để hỗ trợ thêm cho trang web bằng cách xem danh sách này có chứa Patreon, kênh YouTube và Bản tin của tôi. Nếu không, có một cái tốt
Mã hóa Tangents [35 bài viết]—Dòng điều hướngLà một giáo viên khao khát học tập suốt đời, tôi thấy rằng không phải tất cả các môn học đều có trọng lượng như nhau. Do đó, một số chủ đề có thể bị bỏ qua do hạn chế về thời gian hoặc các cam kết khác. Cá nhân tôi thấy những cổ vật bị mất này khá thú vị để thảo luận. Đó là lý do tại sao tôi quyết định tung ra cả một loạt phim để làm điều đó. Chào mừng bạn đến với Coding Tangents, một bộ sưu tập các bài viết giải quyết các chủ đề về tình huống khó khăn trong phát triển phần mềm
Trong loạt bài này, tôi sẽ giải quyết các chủ đề mà tôi cảm thấy nhiều học sinh của mình tò mò nhưng chưa bao giờ thực sự có cơ hội khám phá. Trong nhiều trường hợp, đây là những môn học mà tôi nghĩ đáng được tiếp xúc nhiều hơn trong lớp học. Chẳng hạn, bạn đã bao giờ nhận được lời giải thích chính thức về công cụ sửa đổi quyền truy cập chưa?
Trong một số trường hợp, học sinh buộc phải tự học các môn này. Đương nhiên, điều này tạo thành nơi sản sinh ra những quan niệm sai lầm phổ biến trên các diễn đàn trực tuyến như Stack Overflow và Reddit. Với loạt bài này, tôi hy vọng sẽ quay trở lại những điều cơ bản nơi những chủ đề này có thể được giải quyết toàn bộ