Nếu code của bạn không có điều kiện, vòng lặp hay một vài câu lệnh phân chia luồng (control flow statements), nó sẽ rất dễ để đọc. Những lần nhảy code, chia nhánh làm code nhanh chóng trở nên khó đọc. Trong chương này, chúng ta sẽ tìm cách để viết các đoạn mã chia luồng dễ đọc hơn

K E Y I D E A
Make all your conditionals, loops, and other changes to control flow as “natural” as possible—written in a way that doesn’t make the reader stop and reread your code.

Part II: Simplifying Loops and Logic

Trong chương 1, chúng ta đã khám phá cải thiện về mặt bề mặt (nhìn bằng mắt) - surface level - cách đơn giản để cải thiện code của bạn có thể dễ đọc hơn mà không có quá nhiều rủi ro hay nỗ lực.

Trong chương tiếp theo, chúng ta sẽ xem xét sâu hơn, thảo luận về “vòng lặp và logic” trong code của bạn: kiểm soát luồng, biểu thức logic và biến để làm code của bạn hoạt động. Như mọi khi, mục đích của chúng ta là làm cho các phần này trong code của chúng ta dễ hiểu hơn.

Chúng ta sẽ làm điều này bằng cách cố gắng tối thiểu “mental baggage” (hành vi về tinh thần) trong code của bạn. Mỗi khi bạn nhìn thấy 1 vòng lặp phức tạp, 1 biểu thức khổng lồ hoặc 1 số lượng lớn các biến, điều này thêm vào hành lý tinh thần trong đầu của bạn. (kiểu sợ luôn rồi ý =))). Nó yêu cầu bạn nghĩ nhiều hơn và nhớ nhiều hơn. Điều này thì hoàn toàn ngược lại “dễ dàng để hiểu”. Khi code của bạn có quá nhiều hành vi ảnh hưởng tinh thần, bug có nhiều khả năng không được tìm ra, code trở nên khó có thể thay đổi và chúng ta sẽ không mấy vui vẻ khi làm việc cùng nó.

Chapter 7: Making Control Flow Easy to Read

Chapter 8: Breaking Down Giant Expressions

Chapter 9: Variables and Readability

Trong chương trước, chúng ta có nói về cái mà chúng ta nên comment (what). Trong chương này, sẽ nói về cách viết comment rõ ràng và gọn nhẹ

Mục đích của chương này là giúp bạn nhận ra những gì bạn nên comment. Bạn nên nghĩ mục đích của comment là “giải thích cái mà code đang thực hiện” nhưng đó chỉ là 1 phần nhỏ của nó.

Hãy nghĩ 1 chút về layouts (bố cục) của 1 tờ tạp chí - độ dài đoạn văn, chiều rộng của các cột, thứ tự của bài viết và bìa. A good magazine makes it easy to skip around from page to page, but also easy to read straight through..

Trong chương trước, chúng ta đã khám phá việc làm sao để đóng gói các thông tin vào tên của bạn. Trong chương này, chúng ta sẽ tập trung vào 1 chủ đề khác: coi chừng những cái tên có thể bị hiểu nhầm

KEY IDEAD

Chủ động xem xét các tên của bạn bằng cách hỏi chính mình “liệu có nghĩa khác có thể làm cho ai đó giải thích từ tên này”

Bất cứ khi nào bạn đang đặt tên cho 1 biến, 1 hàm hoặc 1 lớp, có rất nhiều nguyên lý giống nhau được áp dụng. Chúng tôi thích nghĩ về tên như 1 comment nhỏ. Thậm chí nó không xuất hiện ở nhiều chỗ, bạn có thể truyền tải nhiều thông tin bằng cách chọn 1 cái tên tốt.

Chúng ta sẽ nói đến vấn đề đầu tiên là cải thiện surface: chọn một cái tên tốt, viết comment tốt và format code gọn gàng. Cách thay đổi này dễ áp dụng. Bạn có thể làm nó “in place” (tại chỗ) mà không phải cấu trúc lại code hoặc thay đổi cách chương trình chạy. Nó cũng có thể cải thiện nó rất nhanh mà không cần mất nhiều thời gian :D

Chủ đề này là rất quan trọng vì chúng ảnh hưởng tới mỗi dòng code trong codebase của bạn. Mặc dù mỗi thay đổi dường như là nhỏ, tổng hợp lại, chúng sẽ tạo ra một sự cải thiện lớn vào codebase. Nếu code của bạn có 1 cái tên tốt, well-written comments và xóa được các khoảng trắng, code của bạn sẽ rất dễ để đọc.

Tất nhiên, có rất nhiều thứ hơn nữa ở dưới surface level ảnh hưởng đến khả năng đọc (và chúng tôi sẽ khám phá nó trong phần sau của cuốn sách). Nhưng những tài liệu trong phần này được áp dụng rộng rãi, không tốn nhiều công, đó là thứ đâu tiên chúng tôi muốn khám phá.

Mục lục của chương bao gồm các chủ đề:

Chapter 2: Packing Information into Names

Chapter 3: Names That Can’t Be Misconstrued

Chapter 4: Aesthetics

Chapter 5: Knowing What to Comment

Chapter 6: Making Comments Precise and Compact

Khoảng 5 năm trước, chúng tôi đã thu thập hàng nghìn các ví dụ về “bad code” (phần lớn là của chúng tôi) và phân tích xem cái gì đã làm nó tệ và các kĩ thuật/nguyên tắc được sử dụng để làm code tốt hơn. Cái mà chúng tôi nhận được là tất cả các nguyên tắc xuất phát từ 1 chủ đề duy nhất.

KEY IDEA
Code should be easy to understand.