What are anti-patterns?

An anti-pattern is a common mistake, or a sign that a program has a problem it has not paid for yet. The pages in this part name the ones that Vishy programs fall into, with what each one costs and how to write the same thing well.

Three things to hold while reading them:

• Matching one does not mean the program must be rewritten. An anti-pattern is a reason to look, not a verdict. Every item says when it does not apply.
• No program is free of them. The ones here were all found in programs that a model or a person had written carefully, and several in programs that had passed verification.
• Every example runs. Each item’s Example and Refactoring is a program file that the guide’s check compiles, runs and verifies whenever the compiler changes. Where the language catches the anti-pattern, the item shows the exact line it prints: the checker’s refusal, or the verifier’s failure with the state and the arguments that broke the rule. Where nothing catches it, the item says so, and that is the point of it: those are the mistakes the person or the model writing the program has to catch, and the chapter “What the verifier cannot see” and the three-kinds-of-code table on What Vishy is not say why.

Every item has the same four parts, and a fifth when there is something to say:

• Name, a unique identifier, so a review can cite it.
• Problem, how it harms and what it costs: a round of writer repair, a bug found late, a rule enforced nowhere.
• Example, a program with the anti-pattern and the prose that points at it, followed by what the tools said about it.
• Refactoring, the changed program, and what the tools say now.
• Additional remarks, the fifth, for the cases where the item does not apply.

The categories, in the order the guide takes them:

1. Contract anti-patterns: mistakes inside one contract or one row, where a bound, an outcome, an example or a property is missing or wrong. These are the cheapest to fix and the most often caught by the tools.
2. Design anti-patterns: mistakes in how units, flows and views are cut, where a fact lives in the wrong place or a rule is kept by nobody.
3. Boundary anti-patterns: mistakes at the edge of the core, where sealed functions and effects take on work the verifier could have seen.
4. Process anti-patterns: mistakes in how a team or a writer stage uses the tools, where a verdict is read as more or less than it says.

The items come from the experiments that shaped the language, from the applications in the repository and from the days on which the tools’ rules were written down. Each is stated as a rule of thumb, and the rule’s source is the run that taught it, not an opinion.