Pragmatic Programmer – Topic 44: Naming Things — Đặt Tên Cho Đúng

Mở đầu

Hồi mới đi làm, mình từng viết một hàm xử lý đơn hàng với biến tên là data2. Hỏi sao có số 2? Vì file đó đã có sẵn một biến data rồi. Vài tuần sau, chính mình đọc lại code của mình mà không hiểu data2 đang chứa cái gì — phải trace ngược cả chục dòng mới biết đó là danh sách các item đã giảm giá. Rồi mình sửa nhầm, gây bug tính sai tiền trên production. Tất cả chỉ vì một cái tên lười biếng.

Topic 44 — Naming Things — trong Pragmatic Programmer nói về đúng chuyện đó. Trong sách có câu mình nhớ mãi: "The name is the thing itself" — cái tên không phải thứ gắn bên ngoài, nó là chính vật đó. Một cái tên tốt truyền tải ý định của code; một cái tên tồi giấu nó đi.

Ảnh: Markus Spiske — Pexels

Nguyên tắc #1: Đặt tên theo ý định, không theo cách thực hiện

Cái tên nên trả lời câu hỏi "thứ này làm gì và vì sao nó tồn tại", chứ không phải "nó được code ra sao". Mình từng thấy một hàm tên là processFiles() — nghe chung chung, nhưng đọc kỹ mới biết nó đang chuyển đổi ảnh sang định dạng WebP. Đáng lẽ nó phải tên là convertImagesToWebP().

# ❌ Tên theo cách thực hiện — đọc xong không biết ý định
def calc(a, b, c):
    return a * b + c

# ✅ Tên theo ý định — ai đọc cũng hiểu ngay
def calculate_total_price(quantity, unit_price, tax_rate):
    return quantity * unit_price + tax_rate

Với hàm trả về boolean, thêm tiền tố is, has, can vào trước — isPasswordValid(), hasPermission(), canRetry(). Chỉ cần nhìn tên là biết hàm trả về kiểu gì, không cần mở body ra xem.

Nguyên tắc #2: Đừng sợ tên dài — sợ tên mơ hồ mới đúng

Ngày xưa màn hình hẹp, người ta thích viết tắt: usr, tmp, buf, n. Giờ IDE nào cũng có autocomplete, gõ 3 ký tự là hiện cả tên dài — nên cái giá của việc viết tắt không còn đáng trả nữa. Một cái tên dài mà rõ ràng còn hơn một cái tên ngắn mà mọi người phải đoán.

// ❌ 5 ký tự, 10 kiểu đoán
n := len(ds)

// ✅ Dài hơn chút, nhưng đọc là hiểu ngay
itemCount := len(discountItems)

Có một ngoại lệ quen thuộc: biến vòng lặp i, j thì không sao — phạm vi của nó chỉ gói trong 3 dòng. Nhưng một biến sống lâu hơn một màn hình code thì bắt buộc phải có tên có nghĩa.

Nguyên tắc #3: Đổi tên là refactoring rẻ nhất — làm ngay khi hiểu thêm

Cái hay của việc đặt tên là nó tiến hoá cùng hiểu biết của mình. Lúc đầu mình đặt tên userList, sau này mới nhận ra nó không phải danh sách user mà là danh sách các user đang chờ duyệt — đổi ngay thành pendingApprovalUsers. Đổi tên không tốn gì nếu làm sớm; càng để lâu, cái tên sai càng in sâu vào đầu người đọc, thành "tên riêng" của thứ đó rồi ai cũng ngại sửa.

Ảnh: rsantos1232 — Pexels

Trong nhóm, nếu thấy tên nào gây hiểu lầm thì đề xuất đổi, đừng sợ làm phiền. Cái giá của một câu hỏi "sao không đổi tên nó thành X nhỉ?" rẻ hơn nhiều so với một bug production gây ra vì hiểu nhầm tên biến.

Kết luận

Đặt tên không phải chuyện văn chương, mà là một phần của việc viết code sạch. Cái tên tốt giúp mình và đồng nghiệp đọc code nhanh hơn, sửa đúng chỗ hơn, và tránh được cả đống bug "vô duyên" kiểu nhầm data với data2.

Lần tới trước khi viết một cái tên, thử dừng lại 5 giây tự hỏi: "Người đọc code này (kể cả mình 6 tháng sau) có hiểu nó đang làm gì không?" Nếu ngập ngừng, đặt tên khác đi — mình tin bạn sẽ thấy khác liền.

Ảnh: digitalbuggu — Pexels