1 | fn Amplitude (X : Vec::<Complex64>, k: usize) -> f64 {
| ^^^^^^^^^ help: convert the identifier to snake case: `amplitude`
warning: variable `X` should have a snake case name
rustc has some built-in warnings that enforce standard code style, such as lower-snake-case names for local variables and functions vs. upper-snake-case names for constants and statics. You can turn these off completely by putting #![allow(nonstandard-style)] in your lib.rs or main.rs.
1 Like
It's standard Rust naming convention.
You can disable it for a single function by putting this on your function:
#[allow(non_snake_case)]
1 Like
many thanks ..I have to use non-snake case because X and x have totally different meanings in the app I'm currently tryng to convert from C++
You can read more about the conventions here. We like camels too.
Also, calling a consistent naming convention a "fetish" is quite a stretch. I'd actually say the phrasing of your question is somewhat offensive to the community.
4 Likes
I apologize.. to anyone offended
Note that there are some syntax gotchas (going back to SML'97 or earlier) that are mitigated by the casing conventions. So watch out for binding-vs-constant in match arms if you're turning off the lints that help catch that.
No offence taken here.
Describing almost anything as a "fetish" has been a common colloquialism in the English language ever since I can remember.
Edit: However it is somewhat a mischaracterisation here. I don't believe anyone particularly enjoys Camel or snake_case but their use in Rust does have a rational.
2 Likes
It seems like you're coming from a C/C++ background? I might be wrong as you probably know more about C/C++ than me, but from my understanding, the C/C++ ecosystem has a variety of semi-formal/inconsistently-agreed-upon competing conventions for capitalization that might be different from project to project.
In my experience, most newer languages (and given that this includes Java, I am using "new" liberally here) tend to have an official convention for capitalization to avoid the ecosystem inconsistency that previous languages experienced. Rust's conventions were codified in an RFC and are described here.
1 Like
@ gretchenfrage...
It seems like you're coming from a C/C++ background Blockquote
correct!..i'm unaware of any C/C++ naming conventions for identifiers.. I am aware of some C/C++ libraries/packages using naming conventions, but these are not imposed by the language.
As an aside.. About 5 hours ago, I started converting 150 lines of C++ code over to Rust just to get a sense of how difficult it would be given my current level of Rust savvy. The C++ code is quite simple: it only has C++ functions that contain the C++ equivalent of a Ruct vec ... no fancy C++ classes, structs etc. ... When I started, I estimated it would take 2 hours max. To anyone coming from C++ over to Rust, my advice is to stay bi-lingual.
Certainly it's a good idea to stay bi-lingual. Or better. Keep up with all the language that you know that are interesting and/or useful. In my case that is Rust, Javascript, C, C++ and Python. In order of preference, from favourite to "under duress". Such code is not going to magically be replaced with Rust over night and I don't think any rustacean would advocate throwing away a bazillion man years of effort in such languages.
What I found interesting was that when converting some big chunks of C# and C++ to Rust it showed up a bunch of potential bugs, or at least bad smells, in the original code. Like uninitialised variables, use after free and such. They did not cause the original code to fail but had gone unnoticed, potential traps for future maintainers.
What I found interesting was that when converting some big chunks of C# and C++ to Rust it showed up a bunch of potential bugs, or at least bad smells, in the original code.> Blockquote
I'm finding the same thing.. but when it comes to rustc complaining about statements like x/n when x is f64 and n is i32 IMHO there should be some #[allow(...) ] to silence rustc complaints..
Rust doesn't do implicit conversions.
The Rust way to do that would be:
x / f64::from(n)
But then what would you expect this to print:
let x = 10.0;
let y = 3;
let z = x / y;
println!("z: {}", z);
"3" or "3.3333333333333335"?
I think it's far better that programmers write what they intend rather than have future readers of the code puzzle over what they meant or introduce potential bugs. Implicit casts in C/C++ are the cause of many a mishap I have seen in code over the years.
I've just changed the title to use "lint".
1 Like
Specific companies may have standards for C++ identifier naming, too. For example, Google’s C++ style guide mandates naming very similar to Rust’s standard naming, apart from constants and macros.
1 Like
Very true, to add onto this good styled code is always a joy to look at and work with
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.