I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

> there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

Isn't this exactly the kind of vague advice that GP was talking about?