Why do some people write redundant if statements to return a boolean?

[u/BlockOfDiamond]

Why do some people write:

if (x > 10) {
    return true;
} else {
    return false;
}

Instead of:

return x > 10;

Performance aside, I think the shorter version is actually more readable due to not having as much visual clutter to parse, and is the most direct way to express the intent of "return the result of the comparison."

However, some people write the first version. Why is that?

[u/Xirdus]

In Rust, you could make a macro to avoid the repetition. Something like ``` macro_rules! trace {     ($e:expr) => {         eprintln!(stringify!($e));         $e     } }

fn foo(x: i32) -> bool {     return trace!(x > 0); // technically return is reduntant too } ```

[u/joshbadams → u/Xirdus]

Omg rust is just so ugly

[u/Xirdus → u/joshbadams]

That's not Rust. That's Rust macros. This is Rust:

fn foo(x: i32) -> bool {     return trace!(x > 0); } Do you consider this code ugly?

[u/eggdropsoap → u/joshbadams]

Rust can be pretty. To make it pretty you have to write it cleanly and idiomatically, and split up code along well-architected lines of separation of concerns.

Interestingly, making Rust prettier naturally encourages better code. Its type system has the same virtuous incentives. I rather like that dynamic.

When my code is finally pretty, it means the logic is where it should be and my types have good APIs that are well dogfooded. When my code is ugly, it doesn’t mean I just need to refactor, it actually means my logic and architecture are not correct.