Disable `Non Snake Case` for module name

Hi all,

I don't know if what I'm asking for is actually possible, but I have created a simple struct:

pub struct OpenTypeFontByteSliceReader<'a> {
    buffer: &'a [u8],
    position: usize,
}

Now, I want to bring some structure to my tests, so I would like to have the tests inside a module which has a specific suffix (UTs for unit tests, ITs for integration tests), so I have a module holding unit tests for this struct:

#[cfg(test)]
mod OpenTypeFontByteSliceReaderUTs {
}

Of course, there's a warning when running the tests that the name should be converted to snake case, but then I don't find it readable anymore.

I know that I can apply #![allow(non_snake_case)] to the file, but then the entire file is affected (and the struct with it's implementation is also in this file), and for these functions, I do want the snake case convention.
I can also move this attribute inside the mod itself, so it's only applicable to the module and it's functions, but I would like to only allow the NON snake case names for the name of the module.

Is something like that possible?

I don't think there's a way to do that directly. Best I can think of is re-exporting a snake case mod as a non snake case one using as, like: use non_snake_case_mod as SnakeCaseMod.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7d4a797368add08793170a32419c618a

By removing the ! the scope is the attached item.

#[cfg(test)]
#[allow(non_snake_case)]
mod OpenTypeFontByteSliceReaderUTs {
}
2 Likes

But that applies the allow to all items within that module as-well, doesn't it?

1 Like

Yes, but I thought that was relevant to what kdeconinck was asking (and nice thing to learn), since it's a test module I don't see much harm in breaking conventions.

1 Like

As far as I understood, OP already tried an approach that put the attribute only on that module

Putting the #![] variant inside instead of the #[] variant outside of the module is AFAIK equivalent, so I guess your suggestion adds some new information regarding syntax, but not too much to solve the problem, over what was already tried.

2 Likes

It seems that it might just be better to stick to the conventions. It would make the code more readable :slight_smile:

2 Likes