Chapter 1: Code Should Be Easy to Understand

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.

Chúng tôi tin rằng nguyên tắc hướng dẫn quan trọng nhất bạn có thể sử dụng khi quyết định code như thế nào. Xuyên suốt cuốn sách, chúng tôi sẽ chỉ ra cách áp dụng những nguyên tắc này với khía cạnh khác nhau để bạn cải thiện khả năng từng ngày. Nhưng trước khi bắt đầu, chúng tôi sẽ giải thích các nguyên tắc này và giải thích tại sao nó lại rất quan trọng.

What Makes Code “Better”?

Đa số lập trình viên (bao gồm cả tác giả) đưa ra các quyết định lập trình dựa vào cảm giác và trực quan. Tất cả những gì chúng ta biết là code như:

for (Node* node = list->head; node != NULL; node = node->next)
    Print(node->data);

sẽ tốt hơn là code:

Node* node = list->head;
if (node == NULL) return;

while (node->next != NULL) {
    Print(node->data);
    node = node->next;
}
if (node != NULL) Print(node->data);

(mặc dù 2 đoạn code thực hiện hành vi như nhau)

Nhưng nhiều lần, 1 sự lựa chọn khó khăn hơn:

return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

tốt hơn hay tệ hơn:

if (exponent >= 0) {
    return mantissa * (1 << exponent);
} else {
    return mantissa / (1 << -exponent);
}

Phiên bản đầu tiên thì gọn nhẹ hơn nhưng phiên bản thứ 2 thì ít đáng sợ. Tiêu chí nào quan trọng hơn? Nói chung, làm sao để bạn quyết định cách nào để code?

Định lý cơ bản về khả năng đọc

Sau khi học nhiều ví dụ như vậy, chúng tôi đi đến kết luận rằng có 1 số liệu cho khả năng đọc quan trọng hơn bất kì số liệu nào khác. Nó rất quan trọng và chúng tôi gọi là “Định lý cơ bản về khả năng đọc”.

KEY IDEA
Code should be written to minimize the time it would take for someone else to understand it.

Điều này có ý nghĩa gì? Theo đúng nghĩa đen, nếu bạn là 1 đồng nghiệp điển hình của chính bạn và thước đó lượng thời gian anh ta cần để đọc code và hiểu nó, thời gian hiểu được là thước đo mà bạn muốn giảm thiểu.

Và khi chúng ta nói “hiểu”, chúng ta 1 biện chứng rất cao cho từ này. Đối với 1 vài người, hiểu đầy đủ code của bạn, họ nên có thể tạo ra sự thay đổi nó, tìm ra lỗi và hiểu nó tương tác như thế nào với phần còn lại của code.

Bây giờ bạn có thể nghĩ, Ai quan tâm nếu người khác có thể hiểu nó? Tôi là người duy nhất sử dụng đoạn code này! Thậm chí nếu bạn là project 1 thành viên, nó cũng có giá trị để theo đuổi mục đích này. “Người nào đó” có thể là bạn 6 tháng sau, khi code của bạn nhìn lạ lẫm với bạn. Và bạn không bao giờ biết - ai đó có thể tham gia dự án của bạn, hoặc “các đoạn mã quẳng đi này” có thể được sử dụng lại ở 1 dự án khác.

Is Smaller Always Better?

Nói chung, bạn viết càng ít code để giải quyết vấn đề thì càng tốt (xem thêm Chapter 13, Writing Less Code). Nó có thể mất ít thời gian hơn để hiểu 1 lớp 2000 dòng hơn là 1 lớp 5000 dòng.

Nhưng ít code hơn chưa phải lúc nào cũng tốt! Có rất nhiều lần khi 1 biểu thức 1 dòng như:

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

Mất nhiều thời gian để hiểu hơn nếu bạn viết 2 dòng:

bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket->IsOccupied());

Tương tự, một comment làm code của bạn có thể hiểu nhanh chóng, mặc dù nó “thêm code” vào file:

// Fast version of "hash = (65599 * hash) + c"
hash = (hash << 6) + (hash << 16) - hash + c;

Bởi vậy, có ít dòng code hơn là 1 mục đích tốt, tối thiểu hỏa thời gian hiểu là thậm chí là 1 mục tiêu tốt hơn.

Does Time-Till-Understanding Conflict with Other Goals?

Bạn có thể nghĩ, những ràng buộc khác thì sao, như làm code hiệu quả hơn, kiến trúc tốt hoặc dễ dàng để test, vân vân? Những ràng buộc này có mẫu thuân với việc làm cho code dễ đọc?

Chúng tôi đã tìm ra mục đích này không can thiệp quá nhiều vào tất cả. Ngay cả trong lĩnh vực mã được tối ưu hóa cao, vẫn có những cách để làm cho nó dễ đọc hơn. Và làm cho code đễ đọc hơn thường dẫn đến việc có 1 kiến trúc tốt và kiểm thử dễ dàng.

Phần còn lại của cuốn sách sẽ thảo luận làm sao để áp dụng “easy to read” trong các hoàn cảnh khác nhau. Nhưng hãy nhớ rằng, khi nghi ngờ, các định lý cơ bản về khả năng đọc bỏ qua bất kì nguyên tắc hoặc quy tắc trong cuốn sách này. Ngoài ra, một số lập trình viên có nhu cầu bắt buộc phải sửa bất kì đoạn code nào không hoàn hảo. Luôn luôn quan trọng khi bạn cần lùi lại các bước và hỏi Đoạn code này đã dễ đọc chưa. Nếu ổn, có thể chuyển sang đoạn code khác.

The Hard Part

Đúng, nó yêu cầu thêm công việc để liên tục nghĩ về việc người ngoài trong tưởng tượng khi tìm code của bạn sẽ dễ hiểu. Làm như vậy đòi hỏi phải bật 1 phần bộ não của bạn, cái mà có thể không bật trong khi code trước đó.

Nhưng nếu bạn áp dụng mục đích này (như chúng tôi đang làm), chúng tôi chắc chắn rằng bạn sẽ trở thành 1 coder tốt, ít lỗi, có nhiều thứ tự hào trong công việc và tạo ra những dòng code mà ai đó xung quanh bạn sẽ yêu thích sử dụng nó. Hãy bắt đầu nào!