I'm translating some of my old C++ code into Rust and get warning messages like
warning: variable `Kmax` should have a snake case name such as `kmax`, #[warn(non_snake_case)] on by default
How can I turn off these compiler warning messages?
In the compiler message #[warn(non_snake_case)] names a warning which was triggered. To suppress it, you can add allow(non_snake_case) attribute to the item in question:
// suppress for the whole module with inner attribute...
#![allow(non_snake_case)]
fn Foo(X: i32) {
let _ = X;
}
// ... or for one function only with anouter attribute
#[allow(non_snake_case)]
fn Bar(Y: i32) {
let _ = Y;
}
And if the Rust code is to be maintained a good option would be to fix the warnings 
4 Likes
Right, in most cases it's better to not disable warnings, and to write rustic code.
2 Likes
Yes, agree.
Except that I don't see any correlation between a style choice and the expected job of a compiler.
So, how, something that should be relevant only locally, the style chosen historically in a company, can generate a warning? It puzzles me.
2 Likes
If you look at Rust code in general most code actually follows similar guidelines and while that may or may not be important to some people I think consistent looking code (esp across the whole ecosystem) is a nice thing to have.
2 Likes
Yeah me too. But then when you don't have a "language standard" people start enforcing their own styles as standards.
3 Likes
When the choice is made for you that's one less thing to worry about 
3 Likes
To be fair, Rust's naming conventions include both pascal case (e.g. for types) and snake case (e.g. for methods), so most people can find something to be annoyed at.
While Rust's convention is not my favorite, the consistency is much more valuable to me than obeying my personal preference. Even if you have a local project with local policies, it's always possible that you will need to use a third party library which can use a different convention. In this case you will be unable to bring all of your code to the same convention, which IMO defeats the purpose of the convention. When I have to use two libraries with different naming conventions in a C++ project, I feel unhappy. But this is also a matter of taste, so if you really want to do it in a local project, there is not much harm to it. If it's a library for public use, disrespecting the Rust convention will just drive people away from your crate.
As a side note: there was time when I hated some conventions and tried to enforce my own preference where possible. But when I quickly switch between languages and libraries, the hate goes away because I get used to seeing code I don't like. As long as it doesn't have objectively bad aspects, any consistent convention is good, especially if it's widely used across the ecosystem.
10 Likes
Thanks, this was very helpful for suppressing these warnings while writing JNI code for Android, which requires very particular names for the functions.
I think consistency is important, but not as important if it does not prevent bad code that causes a system crash. My main objection to the current "consistent" "laws" some people seem "married to" is placing important information at the end of a line of code.
eg. " fn abc() {". or "a,b,c,". The syntax errors at the end of the line can be easily overlooked by humans. I have spent too many hours thinking I had coded correctly only to find out a small syntax error causes a big logic problem.
Has anyone thought about a consistent style that places these important symbols at the front of the line?
At the front of the line it is easier to see errors. One problem with placing important information at the end of a line is that each line has a different length. Scanning all of the "end of line positions" is prone to errors. Simple parameters, and if conditions are easy. Trying to read a complex if condition with grouping is another thing. In the complex if condition, being able to break conditions and groups where it seems clarifying, is better than following some agreed upon style.
The continuation comma at the end of a line is bad (for me) in the first place. Now we are modifying the syntax of the language by allowing extra commas at the end of a line when none is required. I found a way around this by placing a comma at the beginning of the next line if there is a next line. In this way I can add or rearrange parameters without having to worry about the comma on the previous line. I even place the ")", or "}" or ";" on a separate line so that it isn't ignored by someone reading the code. (The compiler does not care, at least up until now).
The current standard that I see being force upon programmers, is based upon the compromises of past languages. Borrow a little from here and there. At least that is what someone has said. To me one of the worst choices was borrowing camelCase. Has anyone thought about the impact to dyslexic people. Snake case is a much better choice. It seems the new rule of IT staff is that dyslexics need not apply.
Institualization of Information Technology is what happened to the "Law". Today, we have congressional politicians writing laws as the did in the 19th century. People have to be physically present in order to trust them. We have to sign documents by hand.
The entire legal system is stuck in the 19th or earlier times. How dumb is that? Professionalism becomes over time becomes clericalism. Yes, let's make Information Technology a profession. If that is the case, then I hope AI takes over writing code and puts all of the Lawyers and Information Professionals out of work.
I am not against standard styles, just dumb ones, borrowed from other failed attempts. Why is "fn main() {" smart? Just because some IT practitioners think it is better does not mean they are really smart.
My elegant, clear, obviously sensible, preferred style may well be your "dumb one".
I would be obliged if you would not assume I am dumb.
No matter what syntax and formatting style you came up with there will be people who will moan, whine and complain about it and call it dumb. That is why there are ferocious "language war" debates all over the net that can get pretty heated.
I have come to the conclusion that it's time the programming world grew up, stopped bickering over trivialities and adopted a consistent standard. Some will like it some will not. Tough, man up and deal with it. The important point is to smooth the road for everybody, remove surprises, get along, get stuff done.
Guess what? I'm not totally happy about everything that "rust fmt" complains about. But I accept it anyway. No longer do I have to waste my life fussing and fiddling around with code formatting, getting the case right, etc, etc.
By analogy, I can complain about spelling in the English language, or the fact that people drive on the wrong side of the road, or that they put 10 eggs in a box instead of 12, etc, etc. Well, life goes much easier for everyone as a whole if we all agree on such things and stop whining.
5 Likes
That.
The consistency makes it easy to read code from someone else, in any crate.
1 Like