6 ms·

I prefer to use explicit return statements everywhere -- for greppability.

• berkut 5y ago
  Yep, and read-ability: it's more obvious at a glance where early-exits are.
• ReleaseCandidat 5y ago
  If you have to search for your returns you have either too many or your function is too long ;) I'd even say any return is actually one too many.
  • setr 5y ago
    Half the functions I write follow the format If !validation_rule1 { return default/err } If !validation_rule2 { return default/err } Work… If !validation_rule3 { return default/err } Work… return result/success Don’t know how you’d get away with single return except by horrifically nesting conditionals
    • dragonwriter 5y ago
      > Don’t know how you’d get away with single return except by horrifically nesting conditionals That pattern is addressed by chained not nested conditionals, which can then be wrapped in a match, i.e.: if !validation1 { err1 } else if !validation1 { err2 } . . . else { ...work...; success_result } the error checking part can be reduced to an iteration with appropriate definitions of a structure for the data to be validated, etc., like: match validators.find_map(|v| v(data)) { Some(err) => err, None => { ...work...; success_result } } EDIT: I missed the intermediate work steps in your post when I initially wrote the response. That can be done a number of ways, e.g., breaking things up into to chained steps (each of which might use the above pattern) that mix validation and work and return a Result type with either the data for the next step to consume or an error.
    • ReleaseCandidat 5y ago
      That's what something `bind`-like is for, like Rust's `and_then`. (validation_rule1') .and_then(validation_rule2') .and_then(work1) .and_then(validation_rule3') .and_then(work)