On code style guide

When I write code I follow a very relaxed style guide. The ultimate principle is that every word in your program must serve a purpose. Even consistency is not considered a good thing if it doesn't make code more readable or safe.

1. Comments are not (always) good.

Quite the opposite. The very necessity to write comments means that there is something
wrong with the code (or the language). Don't write comments, write code. If an algorithm is unclear, rewrite it.
If it's too large, decompose it. If it's unclear what a function does, come up with a better name.
If there is a constraint that function parameters need to meet, write this constraint in the language you're using.
As a last resort, write a comment, but remember: your compiler won't read it.

2. Program should be const-correct, but you don't have to use const whenever an object is constant.

If a function parameter points to a constant, it make sense to use const, but it is OK to leave the pointer itself non-const even if it's not modified inside the function: it doesn't really make code more safe, but adds one (useless) word to your program.

If a function argument points to a constant, but it is a simple utility function used only inside one compilation unit, it is OK to omit const. Especially if you would have to write two functions (constant and non-constant) with the same semantics otherwise. You will easily fix this once you really need two separate functions.

3. Inconsistent but right is better than consistent and wrong.

People tend to prefer following a meaningless rule to changing it even if it's clear to everyone that the rule is no longer relevant. This results in ugly code that everyone is afraid to change, because "who knows why it was written like that? I don't believe it was for nothing. The author knew better." and so on.

For new languages it's not that bad, but for languages like C or C++ it's overwhelming how much of so called conventional wisdom there is, that's been irrelevant for decades but still used by programmers of big companies all over the world.

4. There is nothing more valuable than common sense.

You are allowed (and encouraged) to ignore the rule if you see that it's not applicable to your problem. But remember, you are responsible for the code you write. If you don't really know why the rule is there, you shouldn't just ignore it, better be safe than sorry. Having said that, I think it's better if you do find out why and decide whether it applicable or not, don't use this "better be safe than sorry" as an excuse for replicating meaningless garbage.