I would like to know if there are any proposals for internal file organization, like what to put from top to bottom…

Example: start with pub use declarations, then use, the mod, enums, traits, etc.

I’ve seen rustfmt has some options like reorder_imports that may impose some partial structure, but I would like a more comprehensive guide/spec…

If there’s nothing like that. Can we maybe discuss something that makes sense? 🤔

  • lemming_7765@lemmy.mlOPEnglish
    1·
    2 years ago

    That’s more or less what I do. However I usually struggle with enum, traits, functions and structs inside the same group. So, for example, if I’m in the public group:

    1. do I mix them all and sort alphabetically or hierarchically (like the post https://lemmy.ml/comment/414806 suggests)?
    2. do I put enums, traits and functions first since they are usually prerequisites for the following types? Meaning that an enum will probably be used in a struct or trait, so we may want to present it before to the reader.
    3. any other sorting…

    🤔

    • Ephera@lemmy.mlEnglish
      3·
      2 years ago

      I would also definitely recommend hierarchical sorting. So, at the top would be a type typically used when calling your API or the aggregate type holding your internal state etc. and then right below each of these, the types they are composed of.

      Reading code requires sifting through tons of complexity and it requires not-sifting through irrelevant complexity. So, I want to know that I need a type before I care about its precise definition.

      For multiple, not hierarchically related types, I try to put the most important, most frequently used type at the top.

      And I usually put types above functions, as functions can entail a lot of code + details, so I don’t want them ‘displacing’ any relevant types.

      But yeah, I’m not a fan of hard rules and there’s definitely exceptions to these.

      In a codebase at $DAYJOB, we often have Configuration types, which are just boilerplate to read out part of a config file and make it easily accessible to the code in this module.
      No one cares how those Configuration types look, so we place them below all the functions.

      And sometimes, you’ll have a module with many types and not really a reason to deem one more important than the other. Then just sorting them alphabetically can be more readable.

      • lemming_7765@lemmy.mlOPEnglish
        2·
        2 years ago

        Makes sense. I’ve also given a try to the flags I mentioned in rustfmt and they are apparently just for the nightly build, which makes me think they are working on it, which is good news (at least for me).

        Sometimes having too much freedom when it comes to organizing code can be worse, I guess. But in general I prefer it to, for example, C, which was so picky with the placements of things.

        Thanks for the feedback 👍