Guido Von Rossum
Từ một cuộc phỏng vấn với Guido Van Rossum , có thể được nhìn thấy trong toàn văn bản với Books.google.com (nhấn mạnh của tôi):
Sự lựa chọn thụt lề để nhóm không phải là một khái niệm mới trong Python; Tôi đã thừa hưởng điều này từ ABC , nhưng nó cũng xảy ra trong một ngôn ngữ cũ. Tôi không biết liệu các tác giả ABC có ý tưởng từ thỉnh thoảng, hoặc phát minh ra nó một cách độc lập, hoặc nếu có một tổ tiên chung. Tất nhiên, tôi có thể có quyết định không theo sự dẫn dắt của ABC, như tôi đã làm trong các lĩnh vực khác (ví dụ, ABC sử dụng chữ hoa cho các từ khóa ngôn ngữ và tên thủ tục, một ý tưởng tôi đã không sao chép), nhưng tôi đã đến như tính năng khá bit trong khi sử dụng ABC, vì nó dường như loại bỏ một loại tranh luận vô nghĩa phổ biến giữa những người dùng C tại thời điểm đó, về nơi đặt niềng răng xoăn .
Von Rossum được truyền cảm hứng rất nhiều từ ABC , và mặc dù anh ta không phải sao chép tất cả, việc sử dụng thụt đầu dòng được giữ vì nó có thể có lợi trong việc tránh các cuộc chiến tôn giáo.
Tôi cũng nhận thức rõ rằng mã có thể đọc được sử dụng thụt đầu dòng một cách tự nguyện để chỉ ra việc phân nhóm và tôi đã gặp phải các lỗi tinh vi trong mã mà việc thụt lề không đồng ý với nhóm cú pháp sử dụng dấu ngoặc nhọn mà lập trình viên và bất kỳ người đánh giá nào cũng cho rằng việc thụt lề phù hợp với nhóm và do đó không nhận thấy lỗi. Một lần nữa, một phiên gỡ lỗi dài đã dạy một bài học quý giá.
Rossum cũng chứng kiến các lỗi do sự không nhất quán giữa nhóm và thụt lề, và rõ ràng mặc dù chỉ dựa vào thụt lề để cấu trúc mã sẽ an toàn hơn từ lỗi lập trình 1 .
Donald E. Knuth & Peter J. Landin
Trong cuộc phỏng vấn được tham chiếu, Guido đề cập đến ý tưởng sử dụng thụt đầu dòng của Don Knuth. Điều này được trình bày chi tiết trong Bản trích dẫn Knuth Indentation trích dẫn , trong đó trích dẫn Lập trình có cấu trúc với các Báo cáo goto . Knuth cũng tham khảo Peter John Landin 700 ngôn ngữ lập trình tiếp theo (xem phần Thảo luận về thụt lề). Landin đã thiết kế ISWIM trông giống như ngôn ngữ đầu tiên với thụt đầu dòng thay vì các khối bắt đầu / kết thúc. Những bài báo này nói nhiều hơn về tính khả thi của việc sử dụng thụt lề để cấu trúc các chương trình thay vì các lý lẽ thực tế có lợi cho việc đó.
1. Tôi nghĩ rằng trên thực tế đây là một đối số có lợi cho việc có cả cấu trúc nhóm và định dạng tự động, để bắt và phục hồi từ các lỗi lập trình, điều chắc chắn sẽ xảy ra. Nếu bạn thực hiện việc thụt lề trong Python, người gỡ lỗi mã của bạn sẽ phải đoán đúng:
if (test(x)):
foo(x)
bar(x)
Phải barluôn luôn được gọi hoặc chỉ khi thử nghiệm thành công?
Các cấu trúc nhóm nhóm thêm một mức độ dự phòng giúp bạn phát hiện ra một lỗi khi bạn tự động thụt mã của mình. Trong C, mã tương đương có thể được tự động thụt lề như sau:
if (test(x))
foo(x);
bar(x);
Nếu tôi dự định barở cùng cấp độ foo, thì tự động thụt lề dựa trên cấu trúc mã cho tôi thấy rằng có một cái gì đó sai có thể được sửa bằng cách thêm dấu ngoặc xung quanh foovà bar.
Trong Python: Huyền thoại về thụt lề , có một ví dụ được cho là xấu từ C:
/* Warning: bogus C code! */
if (some condition)
if (another condition)
do_something(fancy);
else
this_sucks(badluck);
Đó là trường hợp tương tự như trên, trong Emacs, tôi làm nổi bật toàn bộ khối / chức năng, nhấn Tab và sau đó tất cả mã được giới thiệu lại. Sự khác biệt giữa thụt lề của con người và cấu trúc mã cho tôi biết có gì đó không ổn (điều đó và nhận xét trước đó!).
Bên cạnh đó, mã trung gian nơi thụt lề tắt trong C đơn giản là không đi qua nhánh chính, tất cả các kiểm tra kiểu tại chỗ sẽ khiến GCC / Jenkins hét vào mặt tôi. Gần đây tôi có một vấn đề tương tự như vấn đề được mô tả ở trên trong Python, với một tuyên bố tắt bởi một cấp độ thụt. Đôi khi tôi có mã trong C vượt ra ngoài dấu ngoặc nhọn, nhưng sau đó tôi nhấn Tab và mã thụt lề "sai": đó là một cơ hội nữa để thấy lỗi.
let x =1; y = 2; z = 3là hoàn toàn hợp lệ, như làdo { putStrLn $ show x; putStrLn $ show y; putStrLn $ show z; }. Những người không cần phải ở trên cùng một dòng.