Some tricks to improve developing experience

[jerry73204]

The zenoh is quite a giant beast to work on. Let me share some ideas that would improve the developing experience.

Collect std and external imports to one common.rs

I used to have a top level common.rs like this.

pub use std::{
    path::{Path, PathBuf}.
    // ...
};
pub use itertools::Itertools;
//...

and loads the common imports when needed.

use crate::common::*;

Add rustfmt.toml

I prefer the rustfmt.toml to keep the code tidy.

edition = "2018"  # required by rust-analyzer
merge_imports = true
format_code_in_doc_comments = true

In-file mods

This is a little trick that I found useful to organize the code. For whatever a file with more than one types and traits, group them into private mod and export them.

pub use workspace::*;
pub use data::*;

mod workspace {
    use super::*;
    // structs, impls, .., etc
}

mod data {
    use super::*;
    // structs, impls, .., etc
}

Most of them require non-trivial changes. If you are comfortable with them, I can push a PR for this.

[JEnoch]

Hi @jerry73204 ,

Thanks for sharing your ideas with us! We are always happy to improve the quality of our code and the overall user experience. Any suggestion is welcome!

Concerning the timing for applying your suggested changes, we think it's better to wait for an important merge to come from @OlivierHecart 's fork. Beside, we are also thinking about other some other refactoring, for instance on crates organisation and errors management, that should be done at the same time.

In the meantime, we certainly can discuss your points:

Collect std and external imports to one common.rs

It would indeed reduce the imports part. But the problem I see is that it would be harder to check which part of our code is exactly using 1 std or external import. And I think it's useful to have such traceability to check the impact of a possible change of dependency.

rustfmt.toml

Good idea. We didn't spent time to check the possibilities of rustfmt (we use its default conf). We just need to be careful on the changes bring by format_code_in_doc_comments = true since it seems to also affect comments without code in it, and there are some comments for which we would like to keep the current style.

In-file mods

Good idea also.

[jerry73204]

For common.rs, I see it trades the traceability off. I used to find unused deps by cargo-deps, and leave platform dependent types imported in respective file when needed. Another advantage is that we can switch on no_std on and off by placing macros in common.rs.

It seems format_code_in_doc_comments = true touches the alignment in comments. We would disable it for now. For other useful options:

# stable options
edition = "2018"
use_field_init_shorthand = true

# unstable options
merge_imports = true