In Thiền của trăn
|
Một trong những pep's Python sớm nhất là PEP-20, được viết vào năm 2004. Nó liệt kê 19 luận đề hoặc quy tắc liên quan đến lập trình Python được gọi là 'Thiền của Python. ' Ngôn ngữ Python được xây dựng dựa trên các nguyên tắc hướng dẫn này và các quy tắc lần lượt được lấy cảm hứng từ PEP-8, hướng dẫn phong cách ban đầu cho Python do chính Guido van Rossum viết Show
Tác giả của Zen of Python, Pythoneer Tim Peters lâu năm, đã bỏ trống quy tắc thứ 20. Ý tưởng của anh ấy là để Guido đóng góp số 20, nhưng điều đó đã không bao giờ xảy ra. Mục lục 19 quy tắc từ Zen of Python19 quy tắc được liệt kê trong Zen of Python như sau
Cách Zen của Python hiển thị xuyên suốt PythonNhư đã đề cập, các quy tắc này một phần được lấy cảm hứng từ PEP-8, hướng dẫn phong cách Python được viết bởi Guido van Rossum. Cho đến ngày nay, các nhà phát triển Python, đặc biệt là những người làm việc trong chính dự án Python, cố gắng tuân thủ các nguyên tắc này Để làm ví dụ về cách các quy tắc này áp dụng cho ngôn ngữ Python, chúng ta có thể xem quy tắc 13 (nên có một – và tốt nhất là chỉ một – cách rõ ràng để thực hiện). Nó rõ ràng được áp dụng cho cách chúng ta có thể lấy độ dài của một đối tượng trong Python. Xét cho cùng, Python có hàm len() hoạt động trên bất kỳ đối tượng nào có độ dài, chỉ cho chúng ta một cách rõ ràng để lấy độ dài của đối tượng. Ngược lại, một số ngôn ngữ khác không có cách thực hiện được xác định như vậy kết thúc bằng vô số phương thức đối tượng như Tuy nhiên, đó không phải là tất cả cầu vồng và ánh nắng mặt trời. Ví dụ, hiện có ba cách để định dạng chuỗi trong Python
Trong những năm qua, các nhà phát triển Python tiếp tục tìm ra những cách mới và tốt hơn để làm điều này nhưng phải giữ nguyên những cách cũ để tương thích Trứng phục sinh Zen của PythonMột quả trứng Phục sinh nhỏ đã có mặt trong Python từ lâu liệt kê Zen of Python. Bạn có thể kích hoạt trứng Phục sinh bằng cách nhập mô-đun The Zen of Python của Tim Peters là 20 nguyên tắc thiết kế ngôn ngữ Python. Mã Python của bạn không nhất thiết phải tuân theo các nguyên tắc này, nhưng bạn nên ghi nhớ chúng. Zen of Python là một quả trứng Phục sinh, hay trò đùa ẩn giấu, sẽ xuất hiện nếu bạn chạy >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! GHI CHÚ. Thật bí ẩn, chỉ có 19 hướng dẫn được viết ra. Guido van Rosum được cho là đã nói rằng câu cách ngôn thứ 20 bị thiếu là “một trò đùa kỳ quái nào đó của Tim Peters. ” Cuối cùng, những hướng dẫn này là những ý kiến có thể được tranh luận hoặc chống lại. Giống như tất cả các bộ quy tắc đạo đức tốt, đôi khi chúng tự mâu thuẫn để mang lại sự linh hoạt nhất. Đây là cách giải thích của riêng tôi về những câu cách ngôn này Đẹp thì tốt hơn là xấuCác lập trình viên thường viết mã nhanh chóng mà không cần quan tâm đến khả năng đọc. Mặc dù mã không nhất thiết phải đọc được, nhưng bản thân mã của ngôn ngữ Python phải được nghĩ ra, nhất quán và thú vị khi sử dụng. Tất nhiên, không phải tập lệnh nào cũng cần phải đẹp và đẹp là chủ quan, nhưng phần lớn sự phổ biến của Python là do rất dễ làm việc với nó. Rõ ràng là tốt hơn ngầm“Câu cách ngôn này tự giải thích được,” đó sẽ là một lời giải thích khủng khiếp cho bất kỳ câu cách ngôn nào. Tương tự như vậy, sẽ tốt hơn nếu mã dài dòng và rõ ràng. Bạn nên tránh ẩn chức năng của mã đằng sau các tính năng ngôn ngữ tối nghĩa đòi hỏi sự quen thuộc để hiểu đầy đủ Đơn giản là tốt hơn phức tạp. Phức tạp tốt hơn phức tạpHai câu cách ngôn này nhắc nhở chúng ta rằng việc xây dựng bất cứ thứ gì đều có thể được thực hiện bằng các kỹ thuật đơn giản hoặc phức tạp. Với một vấn đề đơn giản, chẳng hạn như xây dựng một chuồng chim, một giải pháp đơn giản sẽ tốt hơn. Mặt khác, chế tạo động cơ tàu hỏa diesel là một vấn đề phức tạp đòi hỏi các kỹ thuật phức tạp. Ngay cả khi về mặt kỹ thuật, bạn có thể chế tạo một động cơ tàu hỏa diesel bằng kỹ thuật chuồng chim, thì có lẽ bạn sẽ phải kết thúc với một sự sắp xếp phức tạp, Rube Goldberg của các bộ phận chuồng chim sẽ không phải là một giải pháp lý tưởng. Thích đơn giản hơn phức tạp, nhưng biết giới hạn của sự đơn giản Căn hộ tốt hơn lồng nhauCác lập trình viên thích sắp xếp mọi thứ thành các danh mục, đặc biệt là các danh mục chứa các danh mục con chứa các danh mục con khác. Những hệ thống phân cấp này thường không thêm tổ chức nhiều như họ thêm bộ máy hành chính. Có thể có mã chỉ trong một mô-đun hoặc lớp trên cùng thay vì chia thành nhiều mô-đun con hoặc lớp con. Nếu bạn tạo các gói và mô-đun yêu cầu mã như Thưa thớt tốt hơn dày đặcCác lập trình viên thường thích nhồi nhét càng nhiều chức năng vào càng ít mã càng tốt, chẳng hạn như một lớp lót như sau. số lượng khả năng đọcMặc dù Các trường hợp đặc biệt không đủ đặc biệt để phá vỡ các quy tắc. Mặc dù tính thực tế đánh bại sự tinh khiếtHai câu cách ngôn này, xuất hiện như một tập hợp, mâu thuẫn với nhau. Lập trình có đầy đủ các “thực tiễn tốt nhất” mà các lập trình viên nên cố gắng đạt được trong mã của họ. Lướt qua các phương pháp này để hack nhanh có thể rất hấp dẫn, nhưng có thể dẫn đến một ổ chuột chứa mã không nhất quán, không thể đọc được. Tuy nhiên, việc cúi xuống để tuân thủ các quy tắc có thể dẫn đến mã rất trừu tượng, không thể đọc được. Ngôn ngữ lập trình Java cố gắng khớp tất cả mã với mô hình hướng đối tượng của nó thường dẫn đến rất nhiều mã soạn sẵn cho cả chương trình nhỏ nhất. Đi qua ranh giới giữa hai câu cách ngôn này trở nên dễ dàng hơn với kinh nghiệm. Và theo thời gian, bạn sẽ không chỉ học các quy tắc mà còn biết khi nào nên phá vỡ chúng Lỗi không bao giờ nên âm thầm trôi qua. Trừ khi im lặng rõ ràngChỉ vì các lập trình viên thường bỏ qua các thông báo lỗi không có nghĩa là chương trình sẽ ngừng phát ra chúng. Lỗi im lặng có thể xảy ra khi các hàm trả về mã lỗi hoặc Khi đối mặt với sự mơ hồ, hãy từ chối sự cám dỗ để đoánMáy tính đã làm cho con người trở nên mê tín. Để xua đuổi ma quỷ trong máy tính của mình, chúng tôi thực hiện nghi lễ thiêng liêng là tắt rồi bật lại. Giả sử điều này sẽ khắc phục bất kỳ vấn đề bí ẩn nào. Tuy nhiên, máy tính không phải là ma thuật. Nếu mã của bạn không hoạt động, đều có lý do và chỉ có tư duy phản biện, cẩn thận mới giải quyết được. Từ chối sự cám dỗ để thử các giải pháp một cách mù quáng cho đến khi điều gì đó có vẻ hiệu quả; Nên có một—và tốt nhất là chỉ một—cách rõ ràng để làm điều đóĐây là một khía cạnh trái ngược với phương châm của ngôn ngữ lập trình Perl, “Có nhiều hơn một cách để làm điều đó. ” Hóa ra có ba hoặc bốn cách khác nhau để viết mã làm cùng một việc là con dao hai lưỡi. bạn có thể linh hoạt trong cách viết mã, nhưng bây giờ bạn phải học mọi cách có thể mà nó có thể được viết để đọc nó. Tính linh hoạt này không xứng đáng với nỗ lực gấp 3 hoặc 4 lần cần thiết để học một ngôn ngữ lập trình Mặc dù ban đầu cách đó có thể không rõ ràng trừ khi bạn là người Hà LanDòng này là một trò đùa. Guido van Rossum, người sáng tạo và BDFL (Nhà độc tài nhân từ cho cuộc sống) của Python, là người Hà Lan. Tuy nhiên, ngay cả câu cách ngôn này cũng không ngăn Python kết hợp ba cách định dạng chuỗi khác nhau Bây giờ tốt hơn là không bao giờ. Mặc dù không bao giờ thường tốt hơn *ngay* bây giờHai câu cách ngôn này cho chúng ta biết rằng mã bị treo hoặc bị kẹt trong các vòng lặp vô hạn rõ ràng là tệ hơn mã không. Tuy nhiên, gần như chắc chắn rằng bạn nên đợi chương trình của mình hoàn thành hơn là để chương trình kết thúc quá sớm với kết quả không chính xác Nếu việc triển khai khó giải thích, thì đó là một ý tưởng tồi. Nếu việc triển khai dễ giải thích, đó có thể là một ý kiến hayPython cố gắng làm cho công việc của lập trình viên dễ dàng hơn thay vì hỗ trợ máy tính để chương trình chạy nhanh hơn. Và các chương trình cần phải dễ hiểu không chỉ bởi lập trình viên đã viết nó mà còn bởi những lập trình viên khác, những người duy trì mã. Hai câu cách ngôn này nhắc nhở chúng ta rằng nếu mã “hiệu năng cao” phức tạp đến mức lập trình viên không thể hiểu và gỡ lỗi, thì đó là mã tồi. Nhưng than ôi, việc giải thích mã chương trình cho người khác dễ dàng không có nghĩa là mã đó không tệ. Lập trình khó Không gian tên là một ý tưởng tuyệt vời—hãy làm nhiều hơn thế nữaKhông gian tên (và cả phạm vi toàn cầu và cục bộ) là chìa khóa để ngăn tên trong một mô-đun hoặc phạm vi xung đột với tên trong một mô-đun hoặc phạm vi khác. Nhưng cũng nên nhớ rằng phẳng tốt hơn lồng nhau. Dù tuyệt vời như thế nào, các không gian tên chỉ nên được tạo để ngăn xung đột đặt tên và không thêm phân loại không cần thiết Giống như tất cả các ý kiến về lập trình, những ý kiến tôi đã viết ở đây có thể bị phản đối hoặc có thể đơn giản là không liên quan đến tình huống của bạn. Tranh luận về cách viết mã hiếm khi hiệu quả như bạn nghĩ. (Trừ khi bạn đang viết cả một cuốn sách chứa đầy ý kiến về lập trình. ) Tại sao chương trình của tôi in Zen of Python?Thiền của Python là quả trứng Phục sinh hay trò đùa ẩn , sẽ xuất hiện nếu bạn chạy lệnh nhập này. >>> nhập cái này The Zen of Python, của Tim Peters Đẹp thì tốt hơn xấu. Rõ ràng là tốt hơn ngầm.
Mô-đun nào in Zen của Python khi được nhập?Ngay khi chúng tôi chọn "nhập cái này", tôi nhận ra rằng chúng tôi chỉ cần triển khai nó. Trăn 2. 2 sắp được phát hành và tôi đã đề xuất rằng chúng tôi tắt thông báo đăng ký và xem " cái này. py " mà khi nhập vừa in Zen của Python.
Điều luật thứ 13 trong Thiền của Python là gì?Python 3 nhấn mạnh vào việc loại bỏ các cấu trúc và mô-đun lập trình trùng lặp, do đó hoàn thành hoặc gần hoàn thành định luật thứ 13 của Zen of Python. " Nên có một -- và tốt nhất là chỉ một -- cách rõ ràng để làm điều đó. "
Phương châm của ngôn ngữ Python là gì?Trái ngược với phương châm "có nhiều cách để làm" của Perl, Python bao hàm quan điểm " nên có một—và tốt nhất là chỉ một—obvious way to do it" philosophy. |
