Zen of Python

>>> import this
The Zen of Python, by Tim Peters

1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.[a]
14. Although that way may not be obvious at first unless you're Dutch.
15. Now is better than never.
16. Although never is often better than right now.[b]
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea – let's do more of those!

1. Beautiful is better than ugly

• Code nên nice, dễ đọc, được tổ chức gọn gàng sạch sẽ → dễ hiểu, dễ maintain.
• Eg:
  • Đặt tên biến dễ hiểu.
  • Breaking long blocks to smaller.
  • Tách nhỏ thành các hàm, có ý nghĩa riêng

2. Explicit is better than implicit

• Code nên rõ ràng, tường minh, không mập mờ / ẩn logic.
• Eg:
  • Sử dụng keyword args trong functions calls thay vì dựa vào vị trí của arguments.

3. Simple is better than complex

• Thẳng thắn, đi vào thẳng vấn đề. Complex code có thể gây khó khăn cho việc đọc/ debug, dẫn tới các dependencies không cần thiết, và lỗi tiềm ẩn.
• Eg:
  • Sử dụng simple loop để duyệt list thường dễ hơn là các cách viết comprehension hoặc complex construct.

4. Complex is better than complicated

• Đi khi code cần complex, nhưng không nhất thiết phải quá phức tạp.
• Eg:
  • Sử dụng advanced algorithm / data structures để giải quyết vấn đề có thể hơi complex, nhưng vẫn có thể dễ hiểu và maitain.

5. Flat is better than nested

• Code nên được tổ chức flat, tránh việc nesting nhiều, hoặc indentation nhiều.
• Eg:
  • Sử dụng returns hoặc guard clauses sớm để tránh nesting in functions.

6. Sparse is better than dense

• Viết thông thoáng dễ nhìn =)) Sử dụng whitespace để làm code trông dễ đọc hơn. Tránh việc nhồi nhét quá nhiều code trên 1 dòng.
• Eg:
  • Breaking long lines of code into multiple lines can make the code more readable.

7. Readability counts

• Giữ mindset Readability khi viết code → Dễ maintain, dễ debug.
• Eg:
  • Đặt tên biến dễ hiểu
  • Comment code nếu cần thiết
  • Follow naming conventions.

8. Special cases aren’t special enough to break the rules

• Code nên follow conventions và best practices, ngay cả trong các trường hợp “đặc biệt”.
• Eg:
  • Sử dụng standard lib để parse date string thay vì viết custom parse, ngay cả trong TH input có unusual.

9. Although practicality beats purity

• Trong 1 vài TH, nên ưu tiên tính thực tế và hiệu quả hơn là follow theo lý thuyết.
• Eg:
  • Sử dụng lib của bên thứ 3 để giải quyết vấn đề sẽ thực tế hơn là việc tự viết giải pháp từ đầu, ngay cả khi lib của bên thứ 3 có add thêm 1 it phức tạp.

10. Errors should never pass silently

• Khi có lỗi xảy ra, nó nên được raise và handle in code, thay vì ignored hoặc silenced.
• Eg:
  • Sử dụng try except else block để handle errors and print errors.

11. Unless explicitly silenced

• Nên raise lỗi, trừ khi lỗi đó được chỉ định cụ thể là sẽ không làm gì.

12. In the face of ambiguity, refuse the temptation to guess

• Không nên đoán/ giả định. Cố gắng làm mọi thứ thật rõ ràng.

13. There should be one - and preferably only one - obvious way to do it

• Luôn có 1 cách đơn giản để làm task này với Python. - PYTHONIC way.
• Eg:
  • Cho 1 mảng, tìm phần tử lớn nhất. Thì Python sẽ cung cấp hàm max()

14. Although that way may not be obvious at first unless you’re Dutch

• Just a joke. Ý là cái principles trên kia, luôn có 1 cách ngắn gọn rõ ràng để làm tasks đó. Nhưng không phải ai cũng nhìn thấy nó ngay lập tức :v

15. Now is better than never

• Write code, thay vì chờ đợi “perfect” moment.

16. Although never is often better than right now

• Đôi lúc cũng nên suy nghĩ 1 chút =))

17. If the implementation is hard to explain, it’s a bad idea

• Code mà khó để giải thích cho người khác, thì code này là code lởm.

18. If the implementation is easy to explain, it may be a good idea

• Ngược lại với số 17

19. Namespaces are one honking great idea – let’s do more of those!

• Namespace rất quan trọng trong việc tổ chức code và loại bỏ việc conflict naming giữa biến và functions.