Not sure how clear you are on your exact target here, given the way you've formulated it - is your main objective "readability & coding style" or "better state handling" with all related to it?
The former is, to a larger extent, simply about moving things around a little bit.
The second is more of an architectural, higher-level, design problem.
Readability-wise, use early returns - for starters.
this is much harder to read
if let Ok(manager) = Manager::new() {
let mut good_bats: Vec<Battery> = Vec::new();
if let Ok(batteries) = manager.batteries() {
for battery in batteries.into_iter().flatten() {
good_bats.push(battery);
}
}
}
compared to this
let Ok(manager) = Manager::new() else { return; }
let mut good_bats: Vec<Battery> = Vec::new();
let Ok(batteries) = manager.batteries() else { return; }
for battery in batteries.into_iter().flatten() {
good_bats.push(battery);
}
Stop mixing different calls to the same methods.
why?
if debug {
log("valetudo_wifi_watcher - json didn't contain valid signal strength.");
} else {
println!(
"{} - valetudo_wifi_watcher - json didn't contain valid signal strength: {}",
timestamp(),
to_string_pretty(&value).unwrap()
);
}
// when
fn log(msg: &str) {
println!("{} - {}", timestamp(), msg);
}
fn log_error(msg: &str) {
eprintln!("{} - {}", timestamp(), msg);
}
Avoid unnecessary scopes.
again, why?
#[tokio::main]
async fn main() -> io::Result<()> {
let mut handles = vec![];
{
let args = Cli::parse();
// ...
}
futures::future::join_all(handles).await;
// ...
}
I don't have the time to go through the whole repo, but these few things alone do make me wonder how much thought you've put into the overall structure of it all beforehand. Are you clear on your first go-to approach to logging and error-handling? Separation of concerns? Locality of behavior?
Pick up Dave Farley's "Modern Software Engineering" and - perhaps even more relevant to the topic at hand - "A Philosophy of Software Design", by John Ousterhout. Until you've committed to memory the change amplification / cognitive load / unknown unknowns trifecta, most of the lines you'll be writing will be turning into "monsters" of its own, sooner or later.