Présentation
Le Google Rust Style Guide formalise les bonnes pratiques de rédaction de code Rust au sein de l’entreprise. Il s’applique aux projets majeurs tels que google3, Android, ChromeOS, Fuchsia et Chrome. Au‑delà du formatage, le guide couvre la conception d’API, l’architecture des crates et les conventions d’importation afin de garantir une cohérence transversale entre les équipes.
Principes de conception et objectifs
Le document s’articule autour de trois objectifs explicites : assurer la lisibilité, favoriser un design d’API robuste et faciliter les Large‑Scale Changes (LSC). Google mise sur la longévité du code ; ainsi, un effort supplémentaire lors de l’écriture est jugé rentable si la règle améliore la compréhension ou la maintenabilité. Le guide s’aligne d’abord sur les recommandations publiques du style Rust, mais il introduit des dérogations lorsqu’elles simplifient les refactorisations massives ou réduisent la charge des outils de transformation.
Organisation des crates et modules
Une règle centrale impose la création de crates petites, idéalement limitées à un seul fichier source. Chaque crate correspond à une règle rust_static_library dans le système de build de Chromium et doit résider dans un répertoire unique ; l’usage de sous‑répertoires est considéré comme un signe que la crate a grossi de façon excessive et doit être découpée. Le module racine peut ré‑exporter les API publiques des sous‑modules, ce qui masque l’implémentation interne aux consommateurs. Les modules feuilles portent le nom de l’entité principale qu’ils exposent (ex. mod foo pour foo.rs), tandis que les modules non‑feuilles ne contiennent que des déclarations et des ré‑exports.
mod absl {
pub use status::absl::*;
pub use strings::absl::*;
}
// Permet d’appeler absl::Status au lieu de status::absl::Status
Ce pattern de glob import est limité aux cas d’interopérabilité C++ où le même espace de noms apparaît dans plusieurs crates Rust. En dehors de ces scénarios, les imports globaux (use super::*, use enum::*, etc.) sont découragés afin de préserver la clarté des dépendances.
Implications pour les LSC et la compilation parallèle
Dans un dépôt de l’ampleur de Chromium, chaque dépendance ajoute un nœud au graphe de construction. En privilégiant des crates fines, Google réduit l’impact de l’ajout d’une nouvelle dépendance : le nœud ajouté est petit, ce qui minimise les recompilations inutiles et améliore le cache de build. De plus, la contrainte d’un répertoire unique par crate simplifie les scripts de refactorisation automatisée, car les outils n’ont pas à parcourir des hiérarchies de dossiers complexes. Cette approche se traduit par des temps de compilation plus courts et une meilleure prévisibilité lors de refontes à grande échelle.
Le guide précise toutefois que les règles d’API sont contraignantes pour le code bibliothèque, mais restent des recommandations fortes pour le code applicatif, où la simplicité et la résolution rapide du problème priment sur la réutilisabilité généralisée.
