This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with #[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.
The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.
Oh so its just referring to writing the mod’s code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I’m already doing that at least!
I don’t understand how to follow this bullet point that I was replying to.
I already know what mod does in a basic sense, I wanted to know what the commenter meant by this.
This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with
#[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.
Oh so its just referring to writing the mod’s code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I’m already doing that at least!