torproject / tor Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
code style improvements for src/rust/protover/ffi.rs #179
code style improvements for src/rust/protover/ffi.rs #179
Conversation
Thanks for the patches! Overall, these changes seem like helpful code style improvements. Which style guide (if any) did you refer to for these? Is it https://github.com/rust-lang-nursery/fmt-rfcs/blob/master/guide/guide.md ?
I would say these are more code style improvements rather than refactoring, because the content of functions hasn't really been rearranged to improve modularity.
I also made a few inline review comments.
| if proto_entry.supports_protocol(&protocol, &version) { | ||
| 1 | ||
| } else { | ||
| 0 |
Why not proto_entry.supports_protocol(&protocol, &version) as i32? Or maybe that should be as c_int?
Alternatively, maybe putting the if-else in a single line as in https://github.com/rust-lang-nursery/fmt-rfcs/blob/master/guide/expressions.md#single-line-if-else
might be good.
Considering rustfmt didn't automatically put it on one line, I assume it's not considered "small", as per this from your link:
...it contains a single else clause, and is small.
I think it's in expression context, because it ends up being the implicitly returned value, so the single line if-else is allowed. It's not part of a larger statement or expression on the same line though, so maybe it's in a gray area, especially given the counterexample later in that section. (There's not enough context to tell if the multiline if-else is the last expression of a larger block.)
| @@ -9,9 +9,9 @@ use libc::c_void; | |||
|
|
|||
| // Define a no-op implementation for testing Rust modules without linking to C | |||
| #[cfg(feature = "testing")] | |||
| pub fn allocate_and_copy_string(s: &String) -> *mut c_char { | |||
| pub fn allocate_and_copy_string(s: &str) -> *mut c_char { | |||
This seems like a good change, and seems to be more aligned with how a lot of idiomatic Rust code takes string parameters.
Yep. The style changes were all made automatically via the |
|
This PR looks good to me! Thanks for changing |
|
@frewsxcv would you be willing to write a changes file? (see https://trac.torproject.org/projects/tor/ticket/26492#comment:9) We can also do this for you if you like because you've allowed maintainers to update your pull request branch. This PR might be in the gray area of things that need a changes file but it does (backwards-compatibly) change an interface. |
https://trac.torproject.org/projects/tor/ticket/26492#comment:2
The text was updated successfully, but these errors were encountered: