P.NAM.01 The naming convention for identifiers in the same crate should use a uniform word order

[Description]

The particular choice of word order is not important, but pay attention to consistency within the crate and consistency with similar functionality in the standard library.

For example:

If the naming of types in crate were in verb-object-error word order, we need to follow the same order when we adding new types.

Here are some error types from the standard library:

• JoinPathsError
• ParseBoolError
• ParseCharError
• ParseFloatError
• ParseIntError
• RecvTimeoutError
• StripPrefixError

All of these use verb-object-error word order. If we were adding an error to represent an address failing to parse, for consistency we would want to name it in verb-object-error order like ParseAddrError rather than AddrParseError.

Note: The AddrParseError of module net in the standard library is an exception. Most of the error types from the standard library follow the verb-object-error word order.

[Bad Case]

#![allow(unused)]
fn main() {
// Bad：Not the "verb-object-error" order, should be `ParseAddrError`
struct AddrParseError {}
}

[Good Case]

#![allow(unused)]
fn main() {
// Good: The order is the same as the standard library
struct ParseAddrError{}
}