Google publica su guía de estilo Rust: reglas clave

¿Qué es la guía de estilo de Rust de Google?

Google hizo pública la guía de estilo que aplica al código Rust que escribe internamente. El documento aclara algo que suele malinterpretarse: estilo no es sólo formato, también incluye criterios de diseño de API e implementación. Su alcance declarado cubre los repositorios donde la compañía usa Rust: google3, Android, ChromeOS, Fuchsia y Chrome. Android, Chromium y otros codebases tienen la intención de empezar a aplicarla, cada uno con su propio nivel de exigencia.

Para un founder, lo más valioso no son las reglas sueltas sino el marco con el que Google decide qué entra en la guía. Los objetivos declarados son cinco:

• Legibilidad antes que facilidad de escritura. El código vive mucho tiempo; el esfuerzo extra al escribirlo se recupera en revisiones futuras.
• Automatización. Google depende de Large-Scale Changes (LSC), refactorizaciones asistidas por herramientas que atraviesan todo el código. Los patrones pensados para que el tooling los procese bien son una decisión de diseño, no un accidente.
• Consistencia con el ecosistema Rust. Donde la comunidad ya tiene convenciones, Google las respeta para reducir la sorpresa y el costo de aprendizaje.
• Que cada regla se gane su lugar. Cada desarrollador y cada revisor debe memorizarlas, así que sólo se incluyen reglas con beneficio tangible.
• Cortar las discusiones menores. Si ya existe una regla, no se vuelve a debatir en cada revisión de código.

¿Qué reglas puedes copiar hoy en tu repositorio?

Algunas de las más directamente aplicables, tal como aparecen en el documento:

• Crates pequeños. En Chromium la preferencia es que un crate concentre una sola abstracción, idealmente en un archivo. Se aceptan crates grandes cuando las reglas de coherencia de traits obligan a juntar tipos y traits, o cuando se construye una librería fundacional.
• Layout plano. Todos los archivos .rs de un mismo rust_library viven en un único directorio, sin subdirectorios para organizarlos. Si separarlos en carpetas parece necesario, es señal de que el crate creció de más. Es una desviación deliberada de la estructura Cargo convencional; la excepción es el código en //third_party que además se compila con Cargo.
• Sin glob imports. Nada de use modulo::*, con excepciones acotadas: use super::* en módulos inline, use enum::* dentro de métodos de ese enum y pub use submodulo::* en módulos intermedios. También se evita definir preludes propios. La razón es operativa: los glob imports encarecen los refactors automatizados y dificultan saber de dónde viene un tipo.
• Un use, un módulo. Cada sentencia use importa items de un solo módulo, en línea con imports_granularity = Module de rustfmt.
• Trait imports dentro de la función, salvo que sus métodos se usen por todo el archivo.
• Tipos sin calificar, funciones calificadas. Se usa Regex, no regex::Regex; en cambio, las funciones de nivel superior de otro módulo se llaman con el nombre del módulo (mem::transmute).
• Nada de APIs en módulos que no son hoja. Los módulos intermedios sólo contienen declaraciones de módulos y re-exports.
• Evitar Rc y Arc. Se prefieren el ownership único y el borrowing, porque los punteros de propiedad compartida agregan overhead en runtime y complejidad propia. La excepción es real: si la estructura de borrowing alternativa sería irrazonablemente compleja de escribir, entender o mantener, se usan, y se decide en revisión.
• Borrows antes que copias profundas. .clone() sólo cuando se necesita de verdad una copia.
• enum en lugar de bool en las APIs, y #[non_exhaustive] en enums públicos y en structs públicos con campos públicos.
• #[must_use] en funciones y tipos donde ignorar el resultado es un error.
• expect antes que unwrap, y format! o write! para concatenar y sustituir.
• Nada de código antes de main() y nada de features inestables.
• Formato con herramienta. El documento fija max_width = 100, hexadecimales en minúsculas y matchers de macros formateados. La omisión de formato con #[rustfmt::skip] sólo se admite para alineación manual puntual o código generado, nunca por preferencia personal.

Hay más cobertura de la que sugiere el índice: newtypes frente a alias de tipo, preferencia por campos con nombre en lugar de tuplas, aceptar impl Into en constructores, cuándo conviene enum y cuándo dyn Trait, cuándo definir un trait y cuándo una implementación inherente, convenciones de nombres para métodos, lifetimes y parámetros genéricos, y criterios sobre cuándo documentar.

¿Por qué Google se sale del estilo estándar de Rust?

La guía sigue las reglas públicas de estilo de Rust y los API Guidelines oficiales siempre que no choquen con ella, y buena parte del formato lo resuelve rustfmt. La desviación es deliberada y tiene un motivo poco habitual en un documento de estilo: allanar el camino a los Large-Scale Changes.

Ese objetivo explica varias decisiones. Un refactor automático que atraviesa todo el código necesita patrones predecibles; los glob imports o un layout de archivos libre lo vuelven frágil. Es el tipo de criterio que una startup descubre tarde, cuando ya tiene veinte personas tocando el mismo repositorio.

Hay un segundo detalle que conviene leer con cuidado: muchas reglas llevan etiquetas de codebase, como [chrome] o [Fuchsia]. No son normas universales ni siquiera dentro de Google; el propio documento separa lo que aplica a un codebase específico de lo general. Antes de adoptar una regla suelta conviene mirar su etiqueta.

La distinción que probablemente más sirva a un equipo chico es la de código de librería y código de aplicación. Para una librería pensada para que la usen otros proyectos, las reglas de diseño de API son vinculantes. Para código de aplicación son una recomendación fuerte: como resuelve un problema específico, debe priorizar simplicidad y directitud por sobre la reutilización amplia, y evitar la generalización prematura.

¿Cómo se conecta con Android, Chrome y la seguridad de memoria?

Google no escribe estas reglas en el vacío: es uno de los mayores usuarios corporativos de Rust. Según ZDNET, el lenguaje llegó a la versión estable 1.0 en 2015 y luego hizo incursiones en Android, Windows, AWS y Meta, además de ser recibido oficialmente por el creador del kernel de Linux, Linus Torvalds; el analista RedMonk lo describió como el favorito de los desarrolladores del momento. Ese crecimiento también obligó a ordenar el estilo: ZDNET reportó la creación de un equipo dedicado a definir el estilo por defecto de Rust, con Josh Triplett, Caleb Cartwright, Michal Goulet y Jane Lusby, cuyo primer trabajo fue cubrir las construcciones del lenguaje que no tenían guía de formato.

El uso de Rust en Google tiene además una motivación de seguridad concreta. En una entrada publicada en el blog de seguridad de Google en abril de 2026, la compañía explicó que integró un parser DNS escrito en Rust dentro del firmware del módem de la serie Pixel 10, y que ya en el Pixel 9 de 2024 había empezado a parchear vulnerabilidades de memoria en ese firmware, que contiene decenas de megabytes de código ejecutable escrito en C y C++ (BGR).

El contexto importa: los módems celulares se pueden atacar de forma remota y Google reportó un interés creciente de atacantes e investigadores en ellos, según BGR. En 2022 la NSA publicó una advertencia pidiendo a las organizaciones usar lenguajes seguros para memoria cuando fuera posible. Y una actualización de 2025 de Google, citada por BGR, indicó que la estrategia redujo los bugs de seguridad de memoria por debajo del 20% del total de vulnerabilidades por primera vez.

¿Qué significa esto para tu startup?

Copia el archivo de configuración antes que el manual. El documento fija opciones explícitas de rustfmt: max_width = 100, hex_literal_case = Lower, format_macro_matchers = true e imports_granularity = Module. Advertencia del propio texto: un codebase puede omitir esas opciones si le importa compilar sobre Rust estable y la opción no está disponible ahí. Una tarde de configuración y un job de CI te ahorran años de diffs ruidosos.

Prohibe los glob imports desde el primer commit. Es la regla más barata de aplicar y la que más se paga cuando el equipo crece: los refactors automatizados y la lectura del código sin herramientas de navegación se vuelven mucho más simples.

Escribe la excepción, no sólo la prohibición. Google no prohíbe Rc, Arc ni .clone(): los desaconseja y obliga a justificar el caso en revisión. Ese formato —regla por defecto más excepción discutible— es más sostenible que un veto absoluto y evita que el equipo discuta lo mismo en cada pull request. Si tu producto expone un SDK, aplica además la separación entre reglas vinculantes para librería y recomendaciones para aplicación.

Un cuarto punto, más de proceso que de código: la guía existe en parte para no re-litigar estilo. Tener el debate una vez, por escrito, cuesta menos que repetirlo en cada revisión.

Conclusión

La guía de estilo de Rust de Google es, en la práctica, documentación de ingeniería gratuita de uno de los mayores usuarios corporativos del lenguaje: qué se permite, qué se desaconseja y por qué. Su regla más útil no es ninguna de las sintácticas, sino el criterio con el que elige: legibilidad por sobre comodidad al escribir, automatización por sobre preferencias personales. Un equipo que adopta dos o tres de estas convenciones —formato automático, cero glob imports, excepciones justificadas en revisión— gana en consistencia sin escribir una línea de política propia.

Fuentes

• Google Rust Style Guide (fuente original)
• Rust programming language outlines plan for updates to style guide
• Your Google Pixel 10 Just Got A Major Security Upgrade