Triết lý Zen của Python là gì và nó truyền cảm hứng như thế nào cho một ngôn ngữ C Zen khả thi.

Khi chúng ta nói về triết lý thiết kế bằng ngôn ngữ của lập trìnhThông thường, những điều sau đây sẽ xảy ra: Triết lý Zen nổi tiếng của Python: tập hợp các câu châm ngôn xuất hiện khi viết import this trong bảng điều khiển. Tuy nhiên, rất dễ nhầm lẫn ý tưởng này với một "ngôn ngữ lập trình Zen C" giả định hoặc với việc tìm kiếm một "Zen" tương đương trong chính ngôn ngữ C. Trên thực tế, những gì chúng ta có là một loạt các nguyên tắc đã truyền cảm hứng cho các cộng đồng như Python và nhiều nhà phát triển đang cố gắng mở rộng chúng sang các ngôn ngữ khác như C, chứ không phải là một ngôn ngữ mới gọi là Zen C.

Trong bài viết này, chúng ta sẽ sử dụng nền tảng đó để giải thích chi tiết về triết lý Zen trong Python là gì, cách thức hoạt động của nó. Triết lý mà nó truyền tải là gì, và đến mức độ nào nó có thể truyền cảm hứng cho một triết lý Thiền giả định của C?Chúng ta sẽ xem xét từng câu châm ngôn một, thảo luận về các ví dụ thực tiễn, sắc thái và những mâu thuẫn thực tế trong quá trình phát triển ngôn ngữ, và kết thúc bằng suy ngẫm về cách áp dụng những nguyên tắc này bên ngoài hệ sinh thái Python.

Thiền thực sự là gì (và tại sao điều đó lại quan trọng khi chúng ta nói về Thiền C)

Cái gọi là Thiền của Python, còn được biết đến với tên gọi PP 20Đây là tập hợp các câu châm ngôn tóm gọn tầm nhìn của Tim Peters về cách thiết kế và viết mã Python. Mặc dù nhiều người trích dẫn nó như thể đó là một loại hiến pháp, nhưng thực chất nó bắt nguồn từ một văn bản khá nhẹ nhàng, với nhiều yếu tố châm biếm và hài hước.

Những câu châm ngôn này được coi là một loại tuyên ngôn về các thực tiễn tốtĐây không phải là các quy tắc chính thức của ngôn ngữ, nhưng chúng đã ảnh hưởng rất lớn đến văn hóa của cộng đồng, việc viết các PEP (Python Enhancement Proposals) và các cuộc tranh luận về sự phát triển của chính ngôn ngữ: từ khi giới thiệu toán tử “walrus” (:=cho đến khi các mô hình cấu trúc khớp nhau.

Khi mọi người nói về "Zen C", nhiều người thực chất đang tự hỏi liệu có một bộ nguyên tắc tương đương nào dành cho ngôn ngữ C hay không, hoặc liệu điều này có thể được điều chỉnh cho phù hợp. triết lý về sự đơn giản, rõ ràng và dễ đọc trong bối cảnh của ngôn ngữ C, một ngôn ngữ cấp thấp hơn và có thiết kế kém "thân thiện" hơn so với Python.

Trên thực tế, khi ai đó nhắc đến Zen C, họ thường muốn diễn đạt cùng một ý tưởng: một vài nguyên tắc hướng dẫn giúp viết mã C rõ ràng và dễ bảo trì hơn, lấy cảm hứng từ triết lý Zen của Python. Không có PEP 20 chính thức nào dành cho C, cũng không có mô-đun "thần kỳ" nào như vậy. import this.

Giao diện của Python's Zen trong bảng điều khiển

Một trong những điều kỳ lạ nổi tiếng nhất của Python là bạn có thể hiển thị Zen trong bất kỳ trình thông dịch tương tác nào chỉ bằng cách gõ lệnh đơn giản. import thisTừ phiên bản Python 2.2.1 trở đi, trình thông dịch đã tích hợp mô-đun này. this.py Khi được nhập khẩu, phần mềm sẽ in các câu châm ngôn bằng tiếng Anh.

Đoạn văn xuất hiện là một chuỗi gồm 19 câu ngắn tóm tắt triết lý thiết kế của Python. Người ta nói rằng Peters đã đề cập đến 20 nguyên tắc, nhưng Ông chỉ để lại 19 tác phẩm., để lại câu thứ hai mươi như một câu châm ngôn "ảo" mà mỗi người có thể tự diễn giải hoặc tự điền vào trong đầu.

Về mặt nội bộ, mô-đun this Nó không lưu trữ Zen dưới dạng văn bản thuần túy, mà dưới dạng một chuỗi được mã hóa. ROT13 Đơn giản thôi. Bản thân mô-đun định nghĩa một từ điển thay thế ký tự và giải mã chuỗi trước khi in ra. Nếu bạn kiểm tra... this.sBạn sẽ thấy phiên bản đã bị làm mờ; nếu bạn áp dụng thuật toán thay thế, bạn sẽ nhận được văn bản dễ đọc.

Việc sử dụng ROT13 này gợi nhớ đến lịch sử: trước khi mô-đun này tồn tại, Zen đã được chia sẻ trên danh sách gửi thư của Python, cũng được mã hóa, như một dạng... Trứng Phục Sinh dành cho cộng đồngÝ tưởng “nhập khẩu cái này” thậm chí còn trở thành khẩu hiệu cho các hội nghị hệ sinh thái thời kỳ đầu, chẳng hạn như Hội nghị Python quốc tế lần thứ 10.

19 châm ngôn Thiền và ý nghĩa thực tiễn của chúng

Văn bản gốc, bằng tiếng Anh, bắt đầu với tiêu đề “Triết lý Python, của Tim Peters” và sau đó trình bày 19 câu mà mọi người dùng Python đều đã từng đọc. Từ đây, chúng ta sẽ xem xét từng câu một, giải thích lý do tại sao. Điều đó hàm ý gì trong việc lập trình hàng ngày?Cách chúng thường được hiểu và một số ví dụ điển hình trong Python giúp chúng ta hình dung cách chúng có thể được chuyển đổi thành "Zen C".

1. Đẹp thì hơn xấu.

Nguyên tắc đầu tiên nhấn mạnh rằng mã không chỉ phải hoạt động mà còn phải Dễ đọcVẻ đẹp ở đây không nằm ở những chi tiết trang trí cầu kỳ, mà ở sự rõ ràng, nhất quán và phong cách tinh tế: tên gọi dễ hiểu, khoảng trống được bố trí hợp lý và cấu trúc mạch lạc.

Một ví dụ kinh điển trong Python là việc ưu tiên sử dụng các toán tử và từ khóa dễ đọc đối với con người, chẳng hạn như... and y or trước mặt biểu tượng Nên sử dụng cách diễn đạt khó hiểu khi có thể, hoặc tránh việc có nhiều thao tác khác nhau chồng chất trên cùng một dòng bằng cách hy sinh tính dễ đọc để đổi lấy sự ngắn gọn.

Ý tưởng tương tự áp dụng cho một Zen C giả định sẽ gợi ý việc sử dụng Quy ước thụt lề rõ ràng, tên mô tả và tách các biểu thức phức tạp thành nhiều dòng, thay vì lạm dụng macro hoặc các biểu thức rắc rối mà chỉ người viết ra chúng mới hiểu.

2. Rõ ràng tốt hơn là ngầm định.

Nguyên tắc này nhấn mạnh rằng người đọc mã không nên phải đoán xem một điều gì đó hoạt động như thế nào. Tốt hơn hết là ý định phải rõ ràng. được viết giữa ban ngàyMặc dù có thể cần thêm một vài dòng mã, thay vì dựa vào hành vi ngầm định hoặc "phép thuật" ẩn giấu.

Một ví dụ rất phổ biến là tránh những điều như... from math import *Điều này đưa toàn bộ nội dung của một mô-đun vào không gian tên hiện tại mà không làm rõ mô-đun nào đang được sử dụng. Tốt hơn là nên viết như sau: from math import sqrt, sin, cos và nêu rõ những gì cần thiết.

Một cách khác để làm cho mã nguồn rõ ràng hơn là giới thiệu các biến trung gian với tên gọi biểu cảm Thay vì dồn tất cả các phép toán vào một biểu thức duy nhất. Điều đó giúp bất kỳ ai (kể cả chính bạn trong tương lai) hiểu được điều gì đang diễn ra mà không cần phải suy luận ngược phức tạp.

3. Đơn giản tốt hơn phức tạp

Ý tưởng ở đây là, khi bạn có lựa chọn, Hãy chọn giải pháp đơn giản thay vì giải pháp phức tạp.Vấn đề không phải là tránh mọi sự phức tạp bằng mọi giá, mà là nhớ rằng mã nguồn chỉ được viết một lần và được đọc nhiều lần.

Các lập trình viên giàu kinh nghiệm thường khẳng định rằng đạt được sự đơn giản cần rất nhiều nỗ lực: bạn phải tinh chỉnh thiết kế, tách các hàm, xem xét lại tên gọi… nhưng đổi lại bạn sẽ có được… Mã sạch và hiệu quả Nó dễ hiểu và có thể được bảo trì mà không cần lo lắng. Cách tiếp cận này hiệu quả với cả Python và C: một hàm ngắn gọn, rõ ràng sẽ tốt hơn một hàm khổng lồ chứa đầy các trường hợp đặc biệt và cờ trạng thái.

Các ví dụ thường so sánh các cách triển khai mà mọi thứ được giải quyết trong một dòng lệnh khó hiểu duy nhất với các phiên bản dài hơn một chút, nhưng với các khối logic rõ ràng và được xác định rõ ràngNhững cách giải thích đó dễ dàng hơn nhiều.

4. Phức tạp hơn rắc rối.

Sự khác biệt giữa “phức tạp” và “rắc rối” là rất quan trọng. Một hệ thống phức tạp bao gồm: các mô-đun đơn giản kết hợpNhưng mỗi thành phần, khi xét riêng lẻ, đều dễ hiểu. Ngược lại, một hệ thống phức tạp lại chứa đầy những mối liên hệ ngầm, các trạng thái chung và logic không dễ nhận ra ngay lập tức.

Trong lập trình, điều này có nghĩa là ưu tiên các thiết kế trong đó mỗi hàm giải quyết một nhiệm vụ rõ ràng và dựa vào các hàm khác được định nghĩa rõ ràng, thay vì dồn tất cả logic vào một chỗ sử dụng các hằng số toàn cục, trạng thái ngầm định và các điều kiện chéo khó theo dõi.

Thứ tự ưu tiên thường được tóm tắt như sau: Đơn giản > Phức tạp > Rắc rốiNói cách khác, nếu không thể hoàn toàn đơn giản, thì ít nhất hãy để sự phức tạp được cấu trúc hóa chứ không phải là một mớ hỗn độn khó hiểu.

5. Dạng phẳng tốt hơn dạng lồng nhau

Cấu trúc lồng ghép sâu là kẻ thù của việc nắm bắt nhanh chóng. Nhiều cấp độ của ifCác vòng lặp lồng nhau và cấu trúc lồng ghép buộc người đọc phải nhồi nhét quá nhiều thông tin vào đầu bạn. đồng thời. Lời khuyên của Thiền là hãy làm phẳng mọi thứ bất cứ khi nào hợp lý.

Một kỹ thuật điển hình để tránh tình trạng làm tổ vô tận là Trích xuất các phần của mã thành các hàm trợ giúp nhỏ.hoặc sử dụng các cấu trúc kiểm soát trực tiếp hơn (chẳng hạn như elif thay vì else: if ... (lồng nhau). Bạn cũng có thể sử dụng các hàm tạo hoặc hàm thuần túy cho phép bạn xử lý các tập hợp mà không cần vòng lặp lồng nhau.

Trong Python, điều này có thể bao gồm việc chuyển đổi ba vòng lặp for lồng nhau thành một chuỗi các hàm tạo được nối tiếp nhau; trong C, phân chia các hàm rất phức tạp thành nhiều hàm đơn giản hơn. Nó giúp giảm bớt sự phức tạp về mặt hình ảnh và logic của mỗi chi tiết.

6. Phân tán tốt hơn là dày đặc.

Mã nguồn cực kỳ nhỏ gọn thoạt nhìn có vẻ thanh lịch, nhưng thường thì nó lại là một vấn đề. nỗi đau cho người phải gánh vác anh taThiền khuyến khích chừa khoảng trống: tách các khối logic thành các dòng khác nhau, thêm khoảng trắng và ngắt dòng khi cần thiết.

Một trường hợp rất điển hình là Bao gồm các câu lệnh điều kiện, câu lệnh return và lời gọi hàm trong cùng một dòng.Điều đó hoàn toàn có thể, nhưng cái giá phải trả để hiểu được lại rất cao. Việc chia nhỏ logic đó thành nhiều dòng với các tên trung gian sẽ giúp luồng xử lý trở nên rõ ràng hơn.

Trong Python, nên sử dụng cú pháp tạo danh sách dễ đọc và các biểu thức ngắn gọn; trong C, điều tương tự cũng áp dụng cho việc sử dụng toán tử, macro và các lệnh gọi nối tiếp, vốn rất được khuyến khích. triển khai theo các bước trung gian khi chúng bắt đầu trở nên khó hiểu.

7. Khả năng đọc hiểu rất quan trọng.

Cụm từ “Khả năng đọc hiểu rất quan trọng” gần như đã trở thành khẩu hiệu của nhóm Python. Thông điệp rất rõ ràng: Mã này được đọc nhiều lần hơn vô hạn lần so với số lần nó được ghi.Vì vậy, nó cần được tối ưu hóa cho người sẽ đọc nó, chứ không phải cho người gõ nó lần đầu tiên.

Chính cú pháp của Python được thiết kế với ưu tiên đó: Việc thụt lề bắt buộc, từ khóa rõ ràng và rất ít cách khác để thực hiện cùng một việc.Trong các ngôn ngữ khác, chẳng hạn như C, khả năng đọc hiểu phụ thuộc nhiều hơn vào phong cách của nhóm: việc sử dụng quy ước đặt tên, các chú thích có ý nghĩa, các mô-đun được định nghĩa rõ ràng, v.v.

Trong cả hai trường hợp, các kỹ thuật như áp dụng nguyên tắc SOLID, lấy cảm hứng từ ý tưởng "Clean Code" hoặc luôn sử dụng tên gọi giải thích rõ mục đích sẽ giúp chương trình bền vững hơn về lâu dài. Các nhà phát triển mới có thể tham gia mà không gặp khó khăn gì..

8. Các trường hợp đặc biệt không đến mức vi phạm quy tắc.

Câu châm ngôn này đề cập đến cám dỗ thường gặp khi nói rằng, “Trường hợp này khác; chúng ta sẽ ngoại lệ ở đây.” Khi định nghĩa một bộ quy tắc về kiểu dáng hoặc thiết kế, nếu Mọi điều kỳ quặc đều được dùng làm cái cớ để bỏ qua chúng.Cuối cùng thì, các quy tắc đều vô dụng.

Thiền gợi ý rằng, ngay cả trong những trường hợp “đặc biệt”, tốt hơn hết là nên cố gắng duy trì tính nhất quánĐiều này có nghĩa là điều chỉnh thiết kế cho phù hợp với từng trường hợp cụ thể, thay vì lén lút đưa vào một lối tắt làm ảnh hưởng đến tính rõ ràng tổng thể của hệ thống.

Nguyên tắc này đặc biệt quan trọng khi thiết kế API, định dạng dữ liệu hoặc hướng dẫn về kiểu dáng trong một nhóm lớn, nơi mà mọi trường hợp ngoại lệ đều представля một thách thức. thêm gánh nặng nhận thức cho mọi người.

9. Mặc dù tính thực tiễn luôn thắng thế so với sự thuần khiết.

Hai phương châm này (quy tắc và tính thực tiễn) cân bằng lẫn nhau. Một mặt, tính nhất quán được đòi hỏi; mặt khác, người ta thừa nhận rằng trong cuộc sống thực tế... Chúng ta không thể lúc nào cũng hoàn toàn "thuần khiết". Trong thiết kế, đôi khi cần phải có những giải pháp nhanh gọn, thực dụng để đáp ứng thời hạn, thích ứng với những hạn chế của môi trường hoặc tạo điều kiện thuận lợi cho việc áp dụng một giải pháp.

Điều quan trọng là không nên quá vội vàng: tính thực tế có thể biện minh cho điều đó. Các giải pháp thực tế để hoàn thành đúng hạnNhưng điều đó không nên trở thành cái cớ để chấp nhận bất kỳ công việc cẩu thả nào. Một ví dụ điển hình trong Python là sử dụng các cấu trúc ngắn gọn khi chúng thực sự cải thiện mã, mà không cần phải dùng đến "phép thuật đen" cần phải giải mã.

Trong một ví dụ giả định về Zen C, điều này sẽ được thể hiện trong các quyết định như sau: Chấp nhận việc sử dụng một số macro hoặc các tối ưu hóa cụ thể. Trình biên dịch khi chúng thực sự cải thiện hiệu suất mà không làm cho mã nguồn trở nên khó hiểu.

10. Không bao giờ được phép bỏ qua sai lầm.

Hướng dẫn này đề cập đến việc xử lý ngoại lệ và lỗi. Cấu trúc khối. try/except hoàn toàn chung chung, chỉ đơn giản là vậy. pass Chúng chắc chắn sẽ dẫn đến những vấn đề khó gỡ lỗi: có gì đó sai sót, không ai nhận ra, và hành vi dường như ngẫu nhiên xuất hiện vài tháng sau đó.

Zen khuyên rằng, trừ những trường hợp quyết định rất có chủ ý, các lỗi nên được làm cho rõ ràng: chỉ nên ghi nhận những loại lỗi đã định, và chúng nên được ghi lại trong... các bản ghiĐó gửi tin nhắn rõ ràng hoặc thậm chí dừng thực thi nếu hệ thống không biết cách khôi phục.

Trong C, thường xuyên bỏ qua mã trả về hoặc không kiểm tra con trỏ null. Đó là cách chắc chắn biến việc bảo trì thành một cơn ác mộng.

11. Trừ khi họ đã bị yêu cầu im lặng một cách rõ ràng.

Cũng như các quy tắc khác, sự tinh tế đóng vai trò quan trọng ở đây. Có những trường hợp bạn biết về một lỗi cụ thể, bạn đã nghiên cứu hậu quả của nó, và bạn quyết định rằng... Điều đó không quan trọng, hoặc bạn cần phải có một cách hành xử có kiểm soát.Trong những trường hợp đó, việc chủ động bịt miệng anh ta có thể là hợp lý.

Một ví dụ điển hình sẽ là bắt giữ ValueError Cụ thể hơn, hãy viết một thông báo gỡ lỗi cho biết rằng vấn đề đã được xử lý đúng cách.mà không cần mở rộng thêm ngoại lệ. Tuy nhiên, điều quan trọng là đó phải là một quyết định có ý thức và được ghi chép lại, chứ không phải là cách để che đậy vấn đề.

Trong ngôn ngữ C, điều tương đương sẽ là Quản lý mã lỗi đã biết bằng cách trả về giá trị mặc định đã được ghi lại., ghi lại sự kiện nếu thích hợp, và chỉ trong ngữ cảnh đó mới bỏ qua lỗi mà không làm ứng dụng bị sập.

12. Khi đối mặt với tình huống mơ hồ, hãy tránh đoán mò.

Câu châm ngôn này nêu bật một cạm bẫy rất phổ biến: tự tưởng tượng ra những thiếu sót khi các yêu cầu, thiết kế, hoặc thậm chí cả mã nguồn đều không rõ ràng. Thiền chủ trương... Đừng tự tạo ra ý nghĩa khi nó không hề có ý nghĩa nào.Nếu có điều gì đó không rõ ràng, tốt nhất là nên đưa ra một quyết định rõ ràng.

Trong lập trình, điều đó thể hiện ở việc đặt tên hàm sao cho chính xác chức năng của chúng, các chú thích làm rõ những giả định quan trọng, và quan trọng nhất là... các bài kiểm tra xác định hành vi dự kiếnNếu không biết điều gì nên xảy ra, đoạn mã sẽ "đoán" và gần như chắc chắn sẽ sai.

Khi nguyên tắc này được áp dụng cho một người có tiềm năng trở thành Zen C, nó sẽ trở thành một lời nhắc nhở thường trực: Đừng cho rằng trình biên dịch, nền tảng hoặc thư viện chuẩn sẽ hoạt động như bạn mong đợi. mà không hề xác minh điều đó trong tài liệu hoặc bằng các thử nghiệm cụ thể.

13. Chỉ nên có một cách rõ ràng duy nhất để thực hiện điều đó.

Nguyên tắc này gần như là cốt lõi trong bản sắc của Python. Trái ngược với những khẩu hiệu như của Perl ("Có nhiều hơn một cách để làm điều đó"), Python nỗ lực đảm bảo rằng, đối với một nhiệm vụ nhất định, Có một con đường được ưu tiên rõ ràng.Điều này giúp đơn giản hóa quá trình học tập và đảm bảo tính nhất quán của mã nguồn từ những người khác nhau.

Một ví dụ kinh điển là việc lặp lại các chuỗi. Trong Python, một phương pháp rất cụ thể được khuyến khích: for elemento in secuencia:Thay vì buộc phải lập chỉ mục thủ công trừ khi thực sự cần thiết, điều này giúp cho các vòng lặp đọc trở nên gần như đơn giản.

Đối với C, tinh thần này có thể được thể hiện qua việc áp dụng, ở cấp độ nhóm, Các mẫu chuẩn cho các hoạt động lặp lạiMột cách thức phổ biến để duyệt mảng, quản lý bộ nhớ hoặc xử lý lỗi, thay vì mỗi lập trình viên tự nghĩ ra phong cách riêng.

14. Mặc dù phương pháp đó thoạt nhìn có vẻ không rõ ràng (trừ khi bạn là người Hà Lan)

Câu châm ngôn này còn thêm một chút hàm ý: cách làm tối ưu không phải lúc nào cũng rõ ràng ngay từ đầu. Thường thì, cần phải làm quen với ngôn ngữ lập trình, các thư viện và hệ sinh thái của nó thì "cách làm hiển nhiên" đó mới trở nên tự nhiên.

Việc nhắc đến người Hà Lan là ám chỉ trực tiếp đến Guido van Rossum, người sáng tạo ra ngôn ngữ lập trình Python, vốn là người Hà Lan. Đối với ông, nhiều quyết định thiết kế có thể mang tính trực giác vì ông biết chính xác mình muốn gì; còn những quyết định khác thì cần nhiều kinh nghiệm hơn. một giai đoạn điều chỉnh và học hỏi.

Điều tương tự cũng sẽ xảy ra trong bất kỳ "lập trình C theo phong cách Zen" không chính thức nào: những điều tưởng chừng hiển nhiên đối với những người lập trình kỳ cựu (cách sử dụng con trỏ, cách sắp xếp tiêu đề, cách cấu trúc dự án) lại có thể rất khó hiểu đối với người mới bắt đầu.

15. Bây giờ là thời điểm tốt hơn bao giờ hết, mặc dù nhiều khi thời điểm không bao giờ tốt hơn chính lúc này.

Hai câu châm ngôn này nói về sự ưu tiên và thời điểm. Một mặt, chúng khuyến khích chúng ta không rơi vào tình trạng tê liệt do phân tích quá mức: Thà có tiến bộ hợp lý còn hơn là không làm gì cả. Chờ đợi một thiết kế hoàn hảo mà chẳng bao giờ xuất hiện. Mặt khác, điều này nhắc nhở chúng ta rằng việc vội vàng thay đổi mọi thứ mà không suy nghĩ kỹ có thể tạo ra những vấn đề tồi tệ hơn.

Trong lập trình, điều đó có nghĩa là Tìm sự cân bằng giữa việc bắt tay vào công việc và tránh việc tùy tiện thay đổi cấu trúc mà không suy nghĩ kỹ.Việc trì hoãn vô thời hạn một số nhiệm vụ quan trọng thường là một ý tưởng tồi, nhưng việc liên tục gián đoạn công việc đang làm để theo đuổi mọi ý tưởng mới cũng chẳng giúp ích gì.

Cách tiếp cận lý tưởng thường là coi sự tiến hóa của hệ thống như một Quy trình lặp đi lặp lại: đưa ra những thay đổi có tính toán và đánh giá tác động của chúng.Hãy tinh chỉnh… và duy trì một danh sách việc cần làm rõ ràng để không bỏ quên những vấn đề quan trọng “mãi mãi”.

16. Nếu việc triển khai khó giải thích, đó là một ý tưởng tồi.

Nếu bạn cần một đoạn văn dài dòng để giải thích cách hoạt động của một đoạn mã, vấn đề có lẽ không nằm ở kỹ năng giao tiếp của bạn, mà là ở chính thiết kế. Câu châm ngôn này khuyến khích sử dụng lời giải thích như một cách diễn đạt trực quan. thiết kế bài kiểm tra sức khỏe.

Khi một quá trình triển khai quá phức tạp đến mức khó có thể diễn đạt bằng những thuật ngữ đơn giản, điều đó thường có nghĩa là có những vấn đề phức tạp khác. quá nhiều trách nhiệm lẫn lộnViệc xác định mối quan hệ phụ thuộc không rõ ràng hoặc các quyết định chưa được hoàn thiện là dấu hiệu cho thấy nên tái cấu trúc mã trước khi chấp nhận phương pháp đó.

Tiêu chí này rất hữu ích trong cả Python và C: Nếu bạn không thể giải thích chức năng hoặc mô-đun đó làm gì chỉ bằng vài câu ngắn gọn thì...Thông thường, luôn có chỗ để cải thiện cấu trúc.

17. Nếu cách triển khai dễ giải thích, đó có thể là một ý tưởng hay.

Mặt khác của luận điểm trên là khi bạn có thể mô tả một giải pháp bằng những từ ngữ rõ ràng, ngắn gọn và dễ hiểu, thì có lẽ bạn đang đi đúng hướng. Điều đó không đảm bảo ý tưởng đó hoàn hảo, nhưng đó là một dấu hiệu tốt cho thấy bạn đang đi đúng hướng. Độ phức tạp đang được kiểm soát..

Nguyên tắc này liên quan rất tốt đến các phương pháp như "kỹ thuật con vịt cao su": việc giải thích bằng lời những gì mã của bạn làm cho người khác (hoặc một vật vô tri) giúp phát hiện ra sự không nhất quán và xác nhận khi nào một điều gì đó được suy nghĩ kỹ lưỡng.

Trong môi trường làm việc nhóm, nếu bất kỳ thành viên nào cũng có thể nhanh chóng hiểu được chức năng của một đoạn mã sau một lời giải thích ngắn gọn, thì việc xem xét, bảo trì và phát triển phần đó của hệ thống sẽ dễ dàng hơn nhiều.

18. Không gian tên là một ý tưởng tuyệt vời: hãy sử dụng chúng nhiều hơn nữa.

Câu châm ngôn cuối cùng nhấn mạnh tầm quan trọng của không gian tên như một công cụ để tổ chức mã và tránh xung đột. Trong Python, các mô-đun, gói, lớp và hàm cung cấp các cấp độ tổ chức khác nhau. sự đóng gói và phân tách trách nhiệm.

Việc sử dụng không gian tên một cách nhất quán cho phép các định danh có cùng tên tồn tại trong các ngữ cảnh khác nhau mà không gây xung đột, đồng thời giúp nhóm các yếu tố liên quan lại với nhau dưới một cấu trúc logic duy nhất. Mở rộng việc sử dụng các cơ chế này thường dẫn đến các kiến ​​trúc có tính mô-đun cao hơn.

Trong ngôn ngữ C, nơi hệ thống không gian tên còn khá thô sơ, ý tưởng này được thể hiện qua các quy ước đặt tên, cấu trúc theo tệp tiêu đề và tệp nguồn, và việc sử dụng có kỷ luật. static và các tiền tố để tránh xung đột. Một "Zen C" hợp lý sẽ mời coi mỗi mô-đun như một không gian tên nhỏ, được định nghĩa rõ ràng..

Bản dịch sang tiếng Tây Ban Nha và những sắc thái văn hóa

Qua nhiều năm, đã có một số bản dịch các câu châm ngôn này sang tiếng Tây Ban Nha được đề xuất. Một số chọn "Đẹp hơn xấu", số khác lại chọn "Đẹp hơn xấu", v.v. Tất cả đều cố gắng giữ nguyên tinh thần của bản gốc, mặc dù một số biến thể là không thể tránh khỏi. những sắc thái tinh tế trong phong cách và cách lựa chọn từ vựng Đặc điểm của người dịch.

Trong tiếng Tây Ban Nha ở Tây Ban Nha, người ta thường dùng các từ như "đẹp", "dễ đọc" hoặc "rõ ràng" để miêu tả mã nguồn, và tránh những "sai sót" hoặc "sửa chữa vội vàng".Ý tưởng tương tự cũng nằm trong triết lý Thiền nguyên thủy, pha trộn giữa giọng điệu nghiêm túc với chút hài hước, đặc biệt là trong câu châm ngôn nói rằng con đường hiển nhiên ban đầu có thể không phải vậy "trừ khi bạn là người Hà Lan".

Những bản dịch này cũng giúp cho văn bản dễ tiếp cận hơn với những người không thông thạo tiếng Anh, mà vẫn không làm mất đi tính ứng dụng của các nguyên tắc. với bất kỳ ngôn ngữ nào và bất kỳ cộng đồng phát triển nàovượt ra ngoài hệ sinh thái Python.

Liệu triết lý Zen của Python là một trò đùa hay một quy tắc bất khả xâm phạm?

Trong chính cộng đồng Python, có một số tranh luận về vị thế chính xác của Zen. Một mặt, nhiều tài liệu chính thức (PEP) coi nó như là động cơ hoặc sự biện minh cho các quyết địnhvà trong các danh sách gửi thư của các nhà phát triển chủ chốt, nó được sử dụng như một lập luận ủng hộ hoặc phản đối các đề xuất cụ thể.

Mặt khác, một số nhà cung cấp dịch vụ bảo trì đã chỉ ra rằng Sử dụng một câu nói Thiền như một vũ khí (“Điều này vi phạm Thiền, do đó nó là xấu”) không phải lúc nào cũng có nghĩa. Thậm chí có những người theo chủ nghĩa chính trị đúng đắn (PEP) bình luận rằng một số câu châm ngôn từng được hiểu là những lời chỉ trích chính ngôn ngữ ngay từ thuở ban đầu và không nên hiểu theo nghĩa đen.

Thực tế là Thiền phát huy hiệu quả tốt nhất khi kim chỉ nam văn hóa và nguồn cảm hứng theo quy tắc thiết kế nghiêm ngặt. Python, với el tiempoNó đã tích hợp các tính năng (như gán giá trị trong biểu thức hoặc khớp mẫu) mà một số người cho là "phức tạp" hơn hoặc ít phù hợp với sự đơn giản ban đầu, nhưng chúng vẫn được chấp nhận vì tính hữu ích của chúng.

Theo nghĩa đó, việc suy nghĩ về một "chữ C Thiền" sẽ liên quan nhiều hơn đến... nắm bắt các nguyên tắc chung Những điều đó giúp viết mã C tốt hơn, mà không có ý định biến chúng thành những quy tắc cứng nhắc cản trở sự phát triển về phong cách hoặc công cụ.

Bộ sưu tập các câu châm ngôn, bản dịch, ví dụ và thảo luận này tạo thành một dạng sơ đồ tư duy về cách chúng ta hiểu "mã nguồn tốt": dễ đọc, càng đơn giản càng tốt, rõ ràng về mục đích và được cấu trúc một cách cẩn trọng. Cho dù bằng Python, C hay bất kỳ ngôn ngữ nào khác, Áp dụng triết lý đó thường tạo nên sự khác biệt giữa một chương trình khó khăn và một chương trình thú vị để thực hiện..