Giải thích các kiểu đặt tên và quy ước

Các kiểu phổ biến

camelCase đôi khi được gọi là lower camel case, còn PascalCase là upper camel case. CONSTANT_CASE còn có tên screaming snake case.

Mỗi ngôn ngữ và định dạng dùng kiểu nào

Phần lớn các hệ sinh thái đã thống nhất quy ước từ lâu, và tuân theo nó giúp mã dễ đọc hơn với bất kỳ ai quen hệ sinh thái đó:

Trong hầu hết ngôn ngữ lập trình, không thể dùng kebab-case cho tên biến vì dấu gạch ngang bị hiểu là dấu trừ: order-total nghĩa là order trừ total.

Từ viết tắt và số

Từ viết tắt là chỗ các quy ước khác nhau nhiều nhất. Một trường phái giữ chúng viết hoa (userID, parseHTML); trường phái khác coi chúng như từ thường (userId, parseHtml). Hướng dẫn phong cách Java và JavaScript của Google theo cách thứ hai, giúp ranh giới từ rõ ràng khi các từ viết tắt đứng cạnh nhau: XmlHttpRequest dễ tách hơn XMLHTTPRequest. Hướng dẫn .NET của Microsoft giữ viết hoa từ viết tắt hai chữ cái (IOStream) và chỉ viết hoa chữ cái đầu của từ dài hơn (HtmlButton). API trình duyệt XMLHttpRequest pha trộn cả hai, nên hay được nhắc đến như một ví dụ cần tránh.

Chữ số không có hoa thường, nên công cụ chuyển đổi không thể biết utf8Decoder là “utf8 decoder” hay “utf 8 decoder”. Công cụ thường gắn số vào từ đứng trước. Hãy chọn một cách viết và dùng nhất quán ở mọi nơi.

Title Case và Sentence case trong tiêu đề

Với tiêu đề tiếng Anh, các cẩm nang văn phong không viết hoa mọi từ theo cùng một cách. Phong cách AP và Chicago để chữ thường cho mạo từ, liên từ và giới từ ngắn, trừ khi chúng đứng đầu hoặc cuối (“The Lord of the Rings”), và hai bên khác nhau ở danh sách cụ thể. Nhiều hướng dẫn về giao diện và tài liệu, kể cả hướng dẫn tài liệu cho nhà phát triển của Microsoft và Google, dùng Sentence case (“Change your password”), vừa dễ áp dụng nhất quán vừa bớt trang trọng.

Title Case của công cụ LeedyBox viết hoa mọi từ, phù hợp với nhãn và tên kiểu biến nhưng không hợp với tiêu đề kiểu báo chí: sau đó hãy tự hạ các từ ngắn về chữ thường.

Chuyển đổi giữa các kiểu làm mất thông tin

Mọi lần chuyển đổi đều tách tên thành các từ trước, dựa vào chữ hoa và dấu phân cách, rồi ghép các từ theo kiểu mới. Những gì kiểu đích không biểu diễn được sẽ mất: parseHTML thành parse_html, và chuyển ngược lại ra parseHtml. Dấu câu cũng bị bỏ, nên “don't” thành hai từ.

Vì vậy hãy coi một kiểu là nguồn chuẩn. Nếu cơ sở dữ liệu dùng snake_case và mã dùng camelCase, hãy chuyển đổi tại ranh giới mỗi lần, theo cùng một chiều, thay vì lưu tên ở cả hai dạng.

Đổi tên khóa ở ranh giới API

Khi front-end dùng camelCase giao tiếp với back-end dùng snake_case, hầu hết thư viện tuần tự hóa có thể tự động ánh xạ tên, nên dữ liệu không bao giờ phải đổi tên bằng tay. Chuyển đổi một tài liệu JSON một lần, chẳng hạn dữ liệu thử hoặc phản hồi mẫu, là việc khác, và chế độ “Khóa JSON” của công cụ làm việc đó mà không đụng đến giá trị.

Hãy chú ý xung đột: user_name và userName thành cùng một khóa ở kiểu nào cũng vậy, và khóa này sẽ ghi đè khóa kia. Các ký hiệu đầu khóa như _id hay $ref thường có ý nghĩa với một cơ sở dữ liệu hoặc lược đồ cụ thể, nên hãy kiểm tra xem có được đổi tên chúng không.

Chữ hoa và chữ thường ngoài tiếng Anh

Quy tắc hoa thường không giống nhau ở mọi ngôn ngữ. Chữ ß của tiếng Đức khi viết hoa thành SS, nên từ dài ra. Tiếng Thổ Nhĩ Kỳ có chữ i có chấm và ı không chấm: cặp chữ hoa của chúng là i → İ và ı → I, trong khi quy tắc mặc định của hầu hết ngôn ngữ lập trình đổi i thành I. toUpperCase() của JavaScript dùng quy tắc mặc định; toLocaleUpperCase('tr') áp dụng quy tắc tiếng Thổ Nhĩ Kỳ. Tiếng Hàn, tiếng Trung và tiếng Nhật hoàn toàn không có chữ hoa thường, nên chỉ có dấu phân cách giữa các từ thay đổi.

Hoa thường cũng có thể quan trọng với tên tệp. Windows và macOS (theo mặc định) coi Readme.md và README.md là cùng một tệp, còn Linux coi là hai tệp. Vì vậy, một lần đổi tên chỉ thay đổi hoa thường có thể không bị phát hiện trên hệ thống này nhưng làm hỏng liên kết hoặc import trên hệ thống khác.

Câu hỏi thường gặp