Clippy also gives us lints that will detect bad coding practices. You should, for example, not import enumeration variants, since enumeration variants should always be prefixed with the actual enumeration. To lint against this practice, you can use the enum_glob_use lint.

Other code practices that might create issues are the panicking From and Into trait implementations. By definition, these traits must never fail, and using unwrap(), expect(), panic!(), or assert!() functions and macros can panic the function. This can be the desired behavior in an application, even though it's bad practice (you should use TryInto and TryFrom traits, or create a new function if developing with the stable compiler).

But the main issue is when developing software such as kernels that could cause the whole OS to panic. You can detect these issues by using the fallible_impl_from lint.

We talked about iterators in Chapter 1, Common Performance Pitfalls, and as we saw, we sometimes have useful functions to wrap filter() and map(). This improves readability, and concatenations of these functions can be detected by using the filter_map lint.

Sometimes, we write conditionals that might not be straightforward to understand, sometimes because we do negations in conditions with else branches or because we add lots of conditions that mess up our comparisons. We have two Clippy lints that will point out these situations: if_not_else and nonminimal_bool.

The first will detect a negation in a conditional, and suggest changing the condition to a positive one and changing the else and the if code sections. The second will check for Booleans that can be simplified to remove redundancy and clean up the code.

Some match statements can also be improved when there are only two branches and one of them does not require any parameters, such as when dealing with Option types. In this case, it's cleaner to change them for an if let expression with an else that will also reduce the indenting of the comparison. These points of failure can be shown by using the single_match_else lint.

Another interesting couple of lints will check for places where you might be adding 1 to an integer just to make comparisons or ranges inclusive. Let's see an example:

    let max = 10;
    for i in 0..max + 1 {
        println!("{}", i);
    }

That code only adds 1 to be able to print the 10 too. You can create an inclusive range of nightly Rust by using an equals symbol after the two range periods (..=):

#![feature(inclusive_range_syntax)]

fn main() {
    let max = 10;
    for i in 0..=max {
        println!("{}", i);
    }
}

The lint that will point out this error is called range_plus_one, while the one that will detect comparisons such as a < b+1, that can be replaced by a <= b, is called int_plus_one.

There are also times where we might change the name of a variable or misspell it and break our code, even if it seems to compile. Other times, we might create variables with too similar names and end up mixing them up. This can be avoided by using the similar_names lint.

Another bad practice is to include the name of an enumeration in a variant of the enumeration, or a structure containing the name of the current module. Since names can be qualified, repetition is not required and adds a lot of text. This will be warned by default, but not in public APIs. You can control that with the stutter and the pub_enum_variant_names lints.

Finally, the same way the Rust compiler gave us a missing_docs lint that would point out missing public documentation, the missing_docs_in_private_items Clippy lint will do the same for private items. This is great to enforce documentation of the whole code base.