Google công bố hướng dẫn phong cách lập trình Rust: Chuẩn mực cho hàng triệu dòng mã nguồn

Google vừa chính thức công bố Hướng dẫn Phong cách Rust (Rust Style Guide) — một tài liệu quy định cách viết mã Rust trên toàn bộ các dự án của hãng, từ Android, ChromeOS, Fuchsia cho đến Chrome. Khác với các hướng dẫn thông thường chỉ tập trung vào định dạng, tài liệu này còn bao hàm cả thiết kế API và kiến trúc triển khai, đánh dấu bước tiến quan trọng trong việc chuẩn hóa ngôn ngữ Rust ở quy mô công nghiệp.

Mục tiêu: Nhất quán, dễ đọc và thân thiện với tự động hóa

Theo tài liệu, Google xây dựng hướng dẫn này dựa trên bốn mục tiêu chính:

• Tính nhất quán lâu dài: Mã nguồn được kỳ vọng tồn tại trong thời gian dài, nên một chút công sức đầu tư ban đầu sẽ mang lại lợi ích về sau.
• Hỗ trợ Thay đổi Quy mô lớn (LSC): Các đợt tái cấu trúc mã nguồn trên diện rộng trở nên dễ dàng hơn khi code có tính nhất quán.
• Hạn chế tranh cãi: Khi đã có quy tắc rõ ràng, các cuộc tranh luận về phong cách trong quá trình review code sẽ giảm bớt.
• Tôn trọng hệ sinh thái: Tận dụng các quy tắc phong cách chính thức của Rust ở mức tối đa, tránh xung đột không cần thiết.

Điểm khác biệt lớn nhất của hướng dẫn Google so với các hướng dẫn thông thường là mục tiêu "làm mượt đường" cho các đợt tái cấu trúc toàn mã nguồn (Large-Scale Changes) — điều mà các công ty khác hiếm khi đặt lên hàng đầu.

Phân biệt mã thư viện và mã ứng dụng

Một điểm cốt lõi trong triết lý của Google là phân biệt rạch ròi giữa hai loại mã:

• Mã thư viện (library code): Các quy tắc về thiết kế API là bắt buộc. Thư viện cần được thiết kế linh hoạt, tái sử dụng cao và hiệu quả về hiệu năng.
• Mã ứng dụng (application code): Các quy tắc thiết kế API chỉ mang tính khuyến nghị mạnh. Mã ứng dụng nên ưu tiên sự đơn giản, trực tiếp thay vì trừu tượng hóa quá mức. Tránh tổng quát hóa và trừu tượng hóa sớm.

Tổ chức crate: Nhỏ gọn và tập trung

Google khuyến khích các crate nhỏ, lý tưởng nhất là chỉ chứa một file duy nhất và tập trung vào một trừu tượng duy nhất. Điều này đặc biệt quan trọng trong Chromium — nơi mã nguồn khổng lồ khiến việc thêm phụ thuộc vào đồ thị build có ảnh hưởng lan rộng.

Trong Chromium, các file .rs thuộc về một crate duy nhất phải nằm trong cùng một thư mục. Không dùng thư mục con để tổ chức file. Nếu cảm thấy cần chia thư mục con, đó là dấu hiệu rõ ràng crate đã quá lớn và cần được tách nhỏ.

Ngoại lệ duy nhất là code Rust trong thư mục //third_party được build bằng Cargo — những trường hợp này có thể theo cấu trúc thư mục Cargo truyền thống.

Quản lý import: Hạn chế tối đa glob import

Google đặt ra các quy tắc khá chặt chẽ về import:

• Không dùng glob import (use module::*), ngoại trừ trường hợp cầu nối với C++ (merging namespace) và một số thư viện bên thứ ba khuyến khích prelude.
• Không lồng :: bên trong khối {..} của câu lệnh use.
• Trait nên được import bên trong thân hàm, trừ khi các phương thức của trait được dùng rộng rãi khắp file.
• Hàm từ module khác nên được gọi kèm tên module (ví dụ modulename::functionname()) thay vì import trực tiếp.
• Kiểu dữ liệu và trait thì ngược lại — nên được tham chiếu không kèm đường dẫn module (dùng Regex, không dùng regex::Regex).

Quản lý bộ nhớ: Ưu tiên sở hữu và mượn

Google khuyến nghị ưu tiên sở hữu duy nhất (unique ownership) và mượn (borrowing) thay vì sử dụng Rc hay Arc để quản lý bộ nhớ. Các con trỏ chia sẻ này tạo thêm chi phí runtime và độ phức tạp riêng.

Cụ thể:

• Chỉ dùng .clone() khi thực sự cần bản sao sâu (deep copy).
• Tránh dùng .clone() thay thế cho việc mượn dữ liệu.
• Khi thiết kế API, hãy nhận tham chiếu đến dữ liệu gốc thay vì tham chiếu đến con trỏ thông minh hay container.

Với thư viện có tính tái sử dụng cao:

• Trả về iterator (impl Iterator hoặc kiểu cụ thể) thay vì Vec.
• Nhận iterator hoặc impl IntoIterator thay vì slice khi chỉ cần duyệt qua input.

Xử lý lỗi: Chọn đúng công cụ cho đúng tình huống

Google đưa ra hướng dẫn rõ ràng về ba cơ chế báo lỗi:

• Option: Dùng cho các lỗi đơn giản, nguyên nhân hiển nhiên (giá trị thiếu, không khớp khi parse).
• Result: Dùng cho lỗi có thể phục hồi, cần ngữ cảnh để xử lý (lỗi I/O, mạng).
• panic!: Dùng để báo hiệu bug và vi phạm bất biến — những lỗi lẽ ra có thể tránh được. Những khuyết điểm này phải được sửa trong code, không phải xử lý lúc runtime.

Macro và sinh mã: Hạn chế tối đa

Thứ tự ưu tiên khi thiết kế API:

1. Hàm, kiểu, trait, đối tượng và module Rust thông thường — tránh macro, sinh mã và metaprogramming khi có thể.
2. Các chiến lược sinh mã khác (như genrule).

Google nhấn mạnh macro có thể tạo ra "phương ngữ" riêng của ngôn ngữ, khiến kỹ sư khó làm việc xuyên suốt mã nguồn. Khi đọc một macro, người đọc có thể đưa ra ít giả định hơn so với code Rust thông thường.

Đặt tên: Theo chuẩn thư viện Rust

Các quy tắc đặt tên của Google khá thực dụng:

• Lifetime phải có tên mô tả rõ ràng, đặc biệt là lifetime của kiểu.
• Generic parameter dùng tên ngắn (một hoặc vài ký tự) liên quan đến loại đối tượng — chữ cái nên gợi ý về trait bound quan trọng nhất. T hoặc U ổn khi ngữ cảnh không ràng buộc (như Vec).
• Extension trait phải có hậu tố ~Ext (ví dụ ForeignTypeExt).
• Constructor: dùng new(), hoặc new_with_foo() nếu có nhiều hơn một. Nếu trả về Result, dùng try_new().
• Chuyển đổi giá trị sang giá trị: dùng from_foo() với triển khai From đi kèm.
• Không viết tắt những từ mà người ngoài dự án khó hiểu, đặc biệt là từ viết tắt và chữ cái đầu.

Văn hóa documentation: Viết những gì code không nói

Google nhấn mạnh tầm quan trọng của comment và documentation:

• Luôn ghi rõ các trường hợp panic của hàm có thể panic do đầu vào không hợp lệ.
• Ghi rõ bất biến của hàm unsafe và trait.
• Không giải thích kiến thức cơ bản về ngôn ngữ lập trình.
• Comment phải nói điều mà code chưa nói — nếu không có gì sâu sắc, tốt hơn là bỏ qua comment hơn là lặp lại tên hàm một cách vô nghĩa.
• Được phép — thậm chí khuyến khích — trộn lẫn doc comment (///, //!) và comment thường (//).

Rust và Python có điểm đặc biệt: không chỉ có quy ước comment khác nhau mà còn có cú pháp hoàn toàn khác biệt. Điều này mang lại lợi ích cụ thể cho hệ sinh thái Rust khi công cụ có thể phân biệt rõ ràng giữa tài liệu công khai và ghi chú triển khai.

An toàn và tránh panic không cần thiết

• Không viết code unsafe trừ khi không còn cách nào khác để triển khai cùng chức năng bằng code an toàn.
• Tránh các thao tác có thể panic khi dữ liệu đầu vào đảm bảo chúng không thể panic. Thay vì dùng Option::unwrap trên giá trị đã biết hợp lệ, hãy dùng pattern matching để chứng minh tính đúng đắn với compiler.
• Khi cần panic do bất biến không thể biểu diễn trong hệ thống kiểu, ưu tiên expect hơn unwrap để ghi lại lý do.
• Cấm sử dụng panic::catch_unwind trong code Rust nội bộ, vì Chrome, Android và Fuchsia đều yêu cầu panic=abort.

Ý nghĩa với cộng đồng lập trình viên Việt Nam

Việc Google công bố công khai hướng dẫn này mang lại nhiều giá trị cho cộng đồng lập trình viên Rust tại Việt Nam:

• Nguồn tham khảo chất lượng cao cho các nhóm phát triển đang chuyển dịch sang Rust.
• Chuẩn mực thiết kế API có thể áp dụng cho các dự án mã nguồn mở trong nước.
• Hiểu biết về cách các tập đoàn lớn quản lý mã nguồn quy mô hàng triệu dòng — bài học quý cho các kỹ sư làm việc trong môi trường doanh nghiệp.

Dù hướng dẫn được thiết kế riêng cho bối cảnh Google, phần lớn các nguyên tắc về thiết kế API, quản lý bộ nhớ và xử lý lỗi đều có thể áp dụng rộng rãi. Các đội ngũ phát triển có thể tham khảo và điều chỉnh cho phù hợp với quy mô và đặc thù dự án của mình.