Ed Page is one of the Rust treasures who I'm moderately convinced isn't actually human and is some other far more efficient and productive life form.
The only real one that catches my eye here is:
Prefer mod.rs over name.rs
Which while I don't disagree with the reasoning given, I find it annoying when I'm grepping for something and I see 40 mod.rs results if my file picker isn't configured (or can't be configured) to show parent directory as well.
I prefer name.rs over name/mod.rs because it eases extracting code to new modules. I'm not necessarily against using name/mod.rs but I've seen very few projects actually adhere to the related requirement to keep implementation code out of mod.rs.
On the other hand,
For example, when browsing on GitHub, ...
I vehemently disagree with this part of the reasoning. No, I don't want to change my development practices to suit one too-big vendor with sub-par UI.
I think you can reasonably substitute that for "any place where the filename is the most relevant information shown"rather than fixating on your perspective on github.
Personally, the benefits of name/mod.rs usually outweigh name.rs + name/, but I do wish there was a third option, the best of both worlds: name/name.rs
I do agree that this should have been possible & the default. Sometimes I've used #[path = "name/name.rs"], but not convinced that this workaround is worth it.
But if you combine his P-MOD advice (the one you refer to) with his P-DIR-MOD advice (mod.rs files only have re-exports), then you don't have that problem.
It's definitely more scaffolding to have an "extra" directory + mod.rs file over just a foo.rs file, but I do think it's the right way to go.
I prefer name.rs over name/mod.rs even knowing the reasons outlined here. They work significantly better in vscode (which is the primary target for rust-analyzer) and other tooling that expects unique filenames.
I prefer imports grouped by module rather than individually as this is a reasonable size that usually fits pretty well. My comparisons for this preference come from evaluating this in Ratatui (which uses grouped by module) vs Codex (where it's a line per individual import). I've found that the merge conflicts are rare in both approaches, and that individual imports add visual noise when reading and writing code that has to be scrolled past (yes you can collapse this, in some places, but you shouldn't have to). It's a small but annoying paper cut that happens on every file open, while a merge conflict happens much less frequently.
https://epage.github.io/dev/rust-style/#m-caller-callee is something I have super strong agreement with and I think it's probably the one that I'd call out as the most important . The rest also feel like I'm in alignment with.
I'd really like to use M-SINGLE-USE in my own code, but unfortunately imports_granularity has been unstable for ages, and rust-analyzer doesn't always follow that convention.
I use imports_granularity = "module" a lot in Ratatui with this setting and haven't seen a problem generally with it. I assume there's other config options for this in other r-a clients.
Ed Page is one of the Rust treasures who I'm moderately convinced isn't actually human and is some other far more efficient and productive life form.
The only real one that catches my eye here is:
Which while I don't disagree with the reasoning given, I find it annoying when I'm grepping for something and I see 40
mod.rsresults if my file picker isn't configured (or can't be configured) to show parent directory as well.I prefer
name.rsovername/mod.rsbecause it eases extracting code to new modules. I'm not necessarily against usingname/mod.rsbut I've seen very few projects actually adhere to the related requirement to keep implementation code out ofmod.rs.On the other hand,
I vehemently disagree with this part of the reasoning. No, I don't want to change my development practices to suit one too-big vendor with sub-par UI.
I think you can reasonably substitute that for "any place where the filename is the most relevant information shown"rather than fixating on your perspective on github.
I do it so I can have a bunch of editor tabs open and not have to search through each to find the correct
mod.rs.Personally, the benefits of name/mod.rs usually outweigh name.rs + name/, but I do wish there was a third option, the best of both worlds: name/name.rs
I do agree that this should have been possible & the default. Sometimes I've used
#[path = "name/name.rs"], but not convinced that this workaround is worth it.Its fine in emacs since if you have two files with the same name they will add the folders above it until they have unique names.
But if you combine his P-MOD advice (the one you refer to) with his P-DIR-MOD advice (mod.rs files only have re-exports), then you don't have that problem.
It's definitely more scaffolding to have an "extra" directory + mod.rs file over just a foo.rs file, but I do think it's the right way to go.
I prefer name.rs over name/mod.rs even knowing the reasons outlined here. They work significantly better in vscode (which is the primary target for rust-analyzer) and other tooling that expects unique filenames.
I prefer imports grouped by module rather than individually as this is a reasonable size that usually fits pretty well. My comparisons for this preference come from evaluating this in Ratatui (which uses grouped by module) vs Codex (where it's a line per individual import). I've found that the merge conflicts are rare in both approaches, and that individual imports add visual noise when reading and writing code that has to be scrolled past (yes you can collapse this, in some places, but you shouldn't have to). It's a small but annoying paper cut that happens on every file open, while a merge conflict happens much less frequently.
https://epage.github.io/dev/rust-style/#m-caller-callee is something I have super strong agreement with and I think it's probably the one that I'd call out as the most important . The rest also feel like I'm in alignment with.
I'd really like to use M-SINGLE-USE in my own code, but unfortunately
imports_granularityhas been unstable for ages, and rust-analyzer doesn't always follow that convention.In VSCode, this helps:
I use imports_granularity = "module" a lot in Ratatui with this setting and haven't seen a problem generally with it. I assume there's other config options for this in other r-a clients.