comply

Identifiers should be kept as short as possible, while still retaining enough meaning that it is immediately clear what it represents- or does.

An identifier that requires more than 31 characters to provide meaning is an indication that complexity might be too high in the specific context and often presents a refactoring opportunity.

Any line of code should fit on the screen it is being viewed on under any scenario; whether single file or side-by-side.

Lines that are too long can be difficult to visually comprehend, and wrapping or scrolling makes it harder to read.

Lines shorter than 80 characters will fit on most viewers, thus improving readability.

A large function can be difficult to read and easily comprehend- especially so if it requires scrolling to fully fit on the screen/display of the viewer.

Basing this rule on a 40 line maximum may seem like an arbitrary number, and while it is certainly not a scientifically proven limit, it does represent a viable breaking point where most displays will be able to keep every line visible.

Additionally, and similar to too-many-params, when a function is getting large and increasingly complex, it is also often a sign that it is doing too much and would likely benefit from being refactored into smaller parts.

Invisible characters (in code, i.e. not in literals) serve no useful purpose and may confuse both editing tools and readers.

The majority of function prototypes will suffer from having unnamed integer parameters, as their meaning might be difficult to derive without.

There are exceptions, of course; a good example is a math function such as max(int, int) where adding parameter names (e.g. int a and int b) would not add value or make it any easier to understand.

In general, however, it is almost always preferable to provide parameter names.

If your code is using a symbol, but not explicitly telling where it got it from, you might have a hard time figuring out just how far your code reaches out.

See require-symbols.

When a function has many parameters, it is often a sign that it is doing too much and would benefit from being refactored into smaller parts.

Each parameter adds to the complexity of a function, and the more it has, the harder it becomes to understand (and use).

A common practice is to bundle parameters into a struct when many parameters are absolutely necessary (a pattern commonly referred to as Parameter Object).

This practice, however, does not reduce the complexity of the function- but it does improve its readability.

A function parameter name might be marked as const in its prototype, but implementations of that function are not required to comply with that- making it an implementation detail that should not be part of the exposed interface.

You might be tempted to save a line or two by not adding braces to that single-line if statement.

However, such a decision may bite you later on, as an unsuspecting programmer may fail to notice the lack of braces and unintentionally be writing code in the wrong scope- leading to potentially undesirable or unpredictable consequences.

This style provides a quick and consistent reading of functions, and helps in reducing line length when return types are long and complicated.

Blank lines are occasionally used as a way of partitioning or grouping chunks of logically separated code, but this is not recommended.

Being explicit about the type and size that you want to use helps improve portability.

It also increases readability as it makes types read more uniformly, and does away entirely with the unsigned and signed keywords.

It's worth noting that when sticking with basic types (e.g. int), the compiler may just do a better job than you at deciding which size is actually the optimal choice.

However, leaving that an implicit choice could result in unexpected issues down the line.

Being explicit lets you avoid making assumptions. The trade-off is potentially losing some (often neglible) performance.

Files that are very long can be difficult to navigate and easily comprehend, and may indicate that the file is too extensive and covering too many things.

Note that, as with func-too-long, this limit is completely arbitrary and only serves as a general indicator of complexity. Whether or not a file is actually too long is highly variable and can only be judged on a situational basis.

The size specification for pointer-degrading array parameters is not enforced by the compiler, thus making it a source of confusion that should be avoided.

For example, you could, without warning, specify one length in a function prototype, but another in the implementation.

A unified header is a header file whose only purpose is to include other header files.

As convenient as they may be, unified headers do not promote modularity and increases compile time in cases where the consumer does not need all of the included headers.

Technically, this is not required for the compiler to do its job, but being explicit helps in keeping a clear and consistent interface.

Helps in determining dependencies that are no longer needed and could be removed, and encourages use of smaller, more well-defined headers.

Fewer dependencies reduce complexity, so being able to remove an inclusion is always an improvement.

By maintaining these lists obsessively you make it much easier for yourself, and others, to determine the actual dependencies of your code.

Padding control keywords improves readability by clearly separating them from macros and function calls.

Using tabs for indentation will produce inconsistent line lengths, as the size of a tab may vary depending on the viewer.

Helps in determining when a symbol is no longer used, potentially leading to being able to remove an inclusion completely, reducing dependencies and improving maintainability.

See require-symbols.

Mostly a matter of convention, but helps in avoiding issues when interacting with the file on the command-line or through external tools.

Placing const qualifiers to the left makes for an inconsistent reading of types.

Helps prevent redundant inclusions and improves compilation times.

Having no padding for *'s makes for an inconsistent reading of types- especially when combined with const qualifiers.

See left-aligned-const.

Additionally, padding provides a clear separation between a declaration and a pointer dereference.

This is advisable to avoid potentially compiling the same unit twice, resulting in multiple symbol definitions and linker errors.

Avoiding header inclusions can help keep compile times low.

Forcing source files to include everything they need helps provide a clear picture on the dependencies of the particular unit and makes it easier to spot redundancies.

These small notes are great for quickly persisting thoughts directly related to specific parts of your code. They serve as reminders for both yourself, and others, that something needs to be looked at eventually.

However, it is dangerous todo-and-forget; in time, these reminders may turn stale- the context might be forgotten, or the issue silently fixed- yet the todo remains.

This is a problem, because future-you may no longer understand why, or even what, is wrong. In such a case, you might not dare deleting it, rendering the todo as nothing but a source of confusion and obfuscation.

Redundant information is never useful. If a parameter can not be named something meaningful, then it is typically better omitted.

This mainly pertains to functions with parameterless declarations.

In C, a function declaration with no parameters is ambiguous, as it implicitly declares a function that can take an arbitrary number of parameters.

A deeply nested scope is often an indication of too high complexity and can be difficult to read.