If the rules in the coding standard are not specific, they won't help. If a rule can be interpreted in multiple ways, it won't be helpful. If the language is too high-level, the usefulness of the coding standard will be very limited. A sentence like

"Dangerous constructs should be avoided as much as possible"

has multiple problems. The term "dangerous constructs" is too vague. Each team member has his own opinion on what is dangerous and what is not. Some of the opinions will match with the coding standard but some won't. The word "should" can be interpreted more or less strictly. The verb "avoid" is clear enough but the end of the sentence messes even that up. The phrase "as much as possible" gives the author a way out. For apparently any reason, he can always use "dangerous constructs". All he needs is a good excuse. This kind of ambiguous, vague, wishy-washy language is not useful in guiding authors in their work or checkers in their checking.

Chapter 2. "Symptoms" goes deep into possible implementations of (code) inspection processes. Here it is assumed that the coding standard is formulated like rules, which is good, as long as the rules are well written. Of course that is what is wrong here. The rules suck. The intention was good, but the implementation doesn't work properly. Tick-the-Code rules are strict and clear.