Analyze HIC++ and figure out if we are missing some important lints

[oli-obk]

http://www.codingstandard.com/section/index/

This document defines a set of rules for the production of high quality C++ code1. The guiding principles of this standard are maintenance, portability, readability and robustness. Justification with examples of compliant and/or non-compliant code are provided for each rule. Each rule shall be enforced unless a formal deviation is recorded (see Section 0.6).

This standard adopts the view that restrictions should be placed on the use of the ISO C++ language (see 1.1.1) without sacrificing its core flexibility. This approach allows for the creation of robust and easy to maintain programs while minimizing problems created either by compiler diversity, different programming styles, or dangerous/confusing aspects of the language.

Without applying good coding standards, programmers may write code that is prone to bugs or difficult for someone else to pick up and maintain.

A combination of techniques has to be applied to achieve high integrity software: e.g. requirements management and coverage testing. Only a few of such techniques are programming language specific, of which language subsetting is widely regarded as an effective and scalable method. When rigorously enforced, and coupled with language agnostic techniques, it can facilitate production of high integrity C++ code.

[Evrey]

I had a brief look at it and came up with the following list. Being an entry in this list does not necessarily mean "ahmagawd I need dat naow", though, just "huh, could be neat".

• Do not comment out code: Can be checked by trying to parse comments and possibly sped up by looking for lots of code-ish stuff in comments like :: or < or i32 first.
• Too similar looking identifiers: Mainly looking for permutations with commonly way too similar looking graphemes depending on the font in use, e.g. stl vs. st1, bigO vs. big0, etc. Heck, maybe even ensure NFKC-normalisation of all the things as a lint. Very costly, though.
• No octal literals: Rust allows leading decimal zeros, which I love, but for projects porting original C/C++ code, you might want a lint for that which warns programmers that octal numbers in Rust must have the 0o prefix.
• No recursion without tail calls: Propably with a hint on how to transform recursive algorithms to iterative ones, and allow(...) by default?
• Don't modify loop counter more than once per iteration: Propably useful for while loops?
• Pass small trivially copyable objects by value: For Rust this means being Copy and up to 2 * mem::size_of::<usize>() in size. I picked this size, because in many calling conventions structs that fit into up to two registers will be passed through registers.
• Do not pass unique_ptr by constant reference: Same for Box, Arc, Rc?
• Avoid too many static code paths: In addition to cyclomatic complexity.

[mcarton]

No octal literals

We already have ZERO_PREFIXED_LITERAL just for that 😄

Too similar looking identifiers

And that's similar_names.

@Evrey Thanks a lot for doing this! For the other ones, could you open a issue per possible lint for ease of tracking and tagging?

[oli-obk]

Do not pass unique_ptr by constant reference: Same for Box, Arc, Rc?

I think we either have an issue or a partial lint already about this

[Evrey]

I though similar_names only checked short identifiers? But anyways, I'll add the others as issues.