- this are rules created to be (kinda/mostly) uniformly applied across all projects at a Google Scale company
Having used rust at work since roughly ~1.0 days I have come to a realization:
- the style guides which work best for "blindly uniformly applied across all kind of projects/teams/people" are not the same as "my preferred style" _in a lot of ways_
- similar they are often not "the best" in every case but they are "uniformly applicable without having to make opinionated decisions" i.e. they don't cause frictions in review or when writing the code due to "style only"-decision without a clear good answer
As a more generic example. There are a lot of frameworks/style guides which lead to related logic being split across 3+ small files in different folders instead of having related code "close together". And this can be a huge pain and isn't how I would manage personal projects. BUT putting code close together will sometimes just not work for various reasons (often shared logic/cross cutting concerns) at which point you will have to make some compromise where/how to place the code which has no simple "no brain used schema-f" solution you can blindly apply no matter what. This can lead to friction. Once too many people touch the same code this tend to become a huge mess, too. So the companies use style guides which split things apart. Even through the outcome is for all the simple cases noticeable worse to work with. As it does scale to large teams, very varying skill levels and many people working on the same code.
- this are rules created to be (kinda/mostly) uniformly applied across all projects at a Google Scale company
Having used rust at work since roughly ~1.0 days I have come to a realization:
- the style guides which work best for "blindly uniformly applied across all kind of projects/teams/people" are not the same as "my preferred style" _in a lot of ways_
- similar they are often not "the best" in every case but they are "uniformly applicable without having to make opinionated decisions" i.e. they don't cause frictions in review or when writing the code due to "style only"-decision without a clear good answer
As a more generic example. There are a lot of frameworks/style guides which lead to related logic being split across 3+ small files in different folders instead of having related code "close together". And this can be a huge pain and isn't how I would manage personal projects. BUT putting code close together will sometimes just not work for various reasons (often shared logic/cross cutting concerns) at which point you will have to make some compromise where/how to place the code which has no simple "no brain used schema-f" solution you can blindly apply no matter what. This can lead to friction. Once too many people touch the same code this tend to become a huge mess, too. So the companies use style guides which split things apart. Even through the outcome is for all the simple cases noticeable worse to work with. As it does scale to large teams, very varying skill levels and many people working on the same code.