| Hi guys, I guess it is time to adopt some consistent standards. Since I wasn't in the room, here are my two cents. # Function docs I prefer putting the function comment *inside* the fn rather than in front. However, I am probably alone on this point, so I'm prepared to lose this fight. Anyhow, if we are going to place comments in front of the function, I think we should encourage `///` comments in favor of the `/**..*/`. That is, prefer this: /// Function comment /// More function comment fn foo() { ... } To this: /** * Function comment * More function comment */ fn foo() { ... } My reasons: 1. No wasted lines (unlike /** ... */ which wastes two lines). 2. If you include a code example inside the `///` comment, you can use `/* ... */` within the comment without triggering errors. 3. It just looks better to my eyes ;) # Module docs I like to make long comments on modules sometimes. I've decided these "book chapter"-like comments ought to be put into a `doc.rs` module, since it's a pain to scroll down through them. # Long function signatures and the opening brace Also, we should give more guidance in the event of long function signatures. Personally, if the first parameter will not fit on the same line as the function names, I favor moving the opening brace to its own line, like this: fn some_really_long_name( a: T1, b: T2) -> RT { ... } The idea is to use the brace at the start of a line to separate code and signature when they have the same indentation. Another relevant example would be what to do if you have a lot of type parameters and traits. I typically do this: fn some_really_long_name<K: Some+Set+Of+Traits, V: Another+Set+Of+Traits>( a: T1, b: T2) -> RT { ... } I think similar rules apply to if statements and so forth: # Pattern syntax I don't like the `|` in front of the patterns. Things don't line up. When using `|` to combine patterns together, and things don't fit on one line, my own personal inclination is to follow a style like this: match foo { pat1 | pat2 => { ... } pat3 | pat4 => { ... } } Here the indentation separates the patterns from everything else. In cases like this, I never use the non-brace form, since otherwise the indentation doesn't work. I also find I prefer using `{...}` form in cases where the body does not produce a value, such as: match foo { Some(v) => { return v; } None => {} } not match foo { Some(v) => return v, None => {} }; Somehow, the `,` strongly suggests a value is being produced to me. # "Ternary operator" If else expressions For cases where you would use the ternary operator in C, such as `(foo ? bar : zed)` I tend to nestle the braces up with the expressions, like so `if foo {bar} else {zed}`. I find this reads better than `if foo { bar } else { zed }`. If others disagree, let me know so I can stop doing it. Niko
|
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
