9 Rust Best Practices - Utils, Examples, Tests (Part 2/3)

Рет қаралды 4,452

Күн бұрын

Пікірлер: 18

@jeffg4686 4 ай бұрын

Something that I get confused on sometimes is when to go with a module versus another crate in the workspace. Is it just that modules evolved first? In a project like C#, I'd just create another assembly, which would pretty much equate to another crate in rust. I actually made very little use of creating custom namespaces within an assembly when coding C#. I see a mod kind of like a namespace - that's what it is mostly, right? I see partitioning for me - regular project specific work (not APIs) as just being separates crates in the workspace. Would you tend to go with a "moduleless" solution (not sure if that's the right word because I guess there's always the initial module of the program. But when you set a dependency to another crate in your project, you don't need modules - just the 'use' import. Anyways, I just wanted to see if people are going with moduleless now? I'm pretty sure they should have gone with namespace instead of mod..., but I digress. I know they wanted it to be "different"

@JeremyChone 4 ай бұрын

First, if you're not sure, I would start with a single crate. Organize concerns into modules and module hierarchy if needed. Then, when the code base approaches 5k LOC (not a perfect metric, but just for the discussion), I think splitting the application into sub-crates makes a lot of sense. Crates have a few more constraints since you cannot have cyclic dependencies. However, this often forces you to have the right level of sub-crates and not go overboard. If our "key modules" are well-designed and independent (have their own errors, etc.), they are typically relatively simple to split out. So, I would say start with modules, and then, when it becomes obvious that multiple crates will help the code grow, go in that direction.

@notwheeliesure 26 күн бұрын

How are you getting region folding in vscode? It doesn't seem to be a default feature. FYI, I am using the official rust-analyzer extension.

@meowsqueak 4 ай бұрын

6:26 Why “lib-utils/”, “lib-core/”, etc and not “lib/utils/” or “lib/core/” for sub crates, to keep it similar to Rust’s name-spacing with mods, rather than by prefix (C style)? Hmm, is “lib/“ a reserved directory name in a workspace?

@JeremyChone 4 ай бұрын

@@meowsqueak Because, when we import it, we know that lib_... is ours and not an external trait. Now, this is just a personal preference. Dev should use what works for them and their team.

@meowsqueak 4 ай бұрын

⁠ah, right, so the prefix “lib-“ is the thing you see and identity as “that’s our crate”? So could be anything really, as you say. Handy! I’m thinking I might use “local-“.

@meowsqueak 4 ай бұрын

This makes me think that crates should be namespaced in general :-/

@JeremyChone 4 ай бұрын

@@meowsqueak Yes, exactly. Could be mystuff-, I just chose lib because it was simple and fitting. Sometimes for other types of libs, I could have worker-... for the worker type of services. In awesomeapp, I have them in lib-worker, but that should be split away. More on that later. Good question though.

@JeremyChone 4 ай бұрын

@@meowsqueak I went back and forth on the top crates folder and saw some other libs/frameworks using "crates/." I found that kind of clear, even if it might sound odd. In doubt, I always opt for clarity.

@RoamingAdhocrat 4 ай бұрын

Kevlin Henney has shamed me out of naming anything "util"

@JeremyChone 4 ай бұрын

Ho, yes this is another debate. I do not have strong opinions either way, and I can see the argument to go with “util.”

@JeremyChone 4 ай бұрын

By the way, I'm not saying there couldn't be another perspective, but in this case, I decided to go with "utils" because this approach involves a set of independent elements without even a common entry point or error, for example. So, my current rule of thumb is that when a module is a bag of related but independent constructs, using the plural might be warranted. However, when something has its own purpose besides grouping a set of things, the singular might be better. Now, it's tricky because sometimes it's not as clear-cut. But again, these things are highly subjective. I would recommend going with whatever the team decides, and if a team member feels strongly about one way, let it be. Consistency is more important.

@solmateusbraga 4 ай бұрын

Imma use "stuff"