Turning off compiler warning messages


#1

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?


#2

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 :slight_smile:


#3

Right, in most cases it’s better to not disable warnings, and to write rustic code.


#4

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.


#5

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.


#6

I just compile like this:

cargo rustc – -Awarnings

I am so sick of underscore nazis. If people don’t like camelCase, then they can stay away from my code.


#7

Yeah me too. But then when you don’t have a “language standard” people start enforcing their own styles as standards.


#8

When the choice is made for you that’s one less thing to worry about :smile:


#9

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.