Rust Style Guide
google.github.io
Style guides for Google-originated open-source projects
  • lobsters__ettolrach@crustaceanson.theshelf.topM
    1·
    19 days ago

    This is overall a very good list. There are probably just these two things which I actively disagree with.

    1. Using the #[non_exhaustive] attribute on every public enum seems like poor advice. Surely you want the caller to get an error when a new variant is added so they can deal with the new logic, rather than having that new stuff go into the fallback arm you had to write?
    2. Listing “code size” as the only exception to using dyn over a generic or impl is probably correct but maybe a bit misleading. Not needing to specify generics up a big chain of types isn’t just difference in text length, it also requires less monomorphisation. The way it’s written now, it sounds like if Google made the Rust standard library, std::fmt::Formatter would have a generic to hold the formatting thing, in addition to its lifetime.

    score 1 · canonical

    • lobsters__epidemian@crustaceanson.theshelf.topM
      1·
      19 days ago

      Do you mean “behave more like Java” is some concrete ways?

      Because, in a general sense, yes, i agree. And it’s what i’d expect from a giant company’s internal code style guidelines TBH. To homogenize style, to optimize for huge amounts of code and for replaceability of parts, and of programmers.

      But i didn’t find any particular points on these Rust guidelines that made me think of what i think of “Java style”. Like, using interfaces and virtual function dispatch for everything, framework-style dependency injection, "POJO"s, incredibly deep package names that serve no purpose, etc. These Rust guidelines seem pretty reasonable honestly; though i didn’t read everything in detail.

      score 1 · canonical

  • lobsters__novedevo@crustaceanson.theshelf.topM
    1·
    19 days ago

    I like to consider my Rust to be pretty stylish, but there are definitely recommendations here I could implement. For instance, I tend towards complicated iterator chains when a for loop is easier to read, and I’m guilty of putting iterator combinators in loop headers. I think I’m a point-free Haskeller at heart :)

    I disagree with Google about crate size, though. Maybe it’s more ergonomic with Google’s internal build tooling, but with Cargo I would definitely rather crates contain more than a few .rs files if the complexity is warranted. To be fair, this section seems to only apply to Chrome, and I know nothing about their build system.

    score 3 · canonical

    • lobsters__refi64@crustaceanson.theshelf.topM
      1·
      19 days ago

      I’m not sure if this applies to GN specifically, but I know a lot of external build systems for Rust don’t support persisting the incremental build caches from a single crate to be reused next time it’s built, so your only unit of incrementalism is at the crate level.

      score 1 · canonical

    • lobsters__siru@crustaceanson.theshelf.topM
      1·
      19 days ago

      This may be out of date, but I thought that incremental builds worked a lot better when there were a lot of crate boundaries. As in if there are a lot of small crates, then those don’t have to be recompiled, but if it is only one large crate, then everything will have to be recompiled.

      score 2 · canonical