The code you paste at the start of a contest, and the tooling you run beside it.
- 📄 Contest Template — the header, macros, and
mainskeleton - 🐛 Debug Macros — a
dbg()that prints any container - 🔨 Stress Testing — generator, brute force, and the runner script
- 📦 Library Snippets — short reference implementations worth having ready
- 💬 Interactive Problems — flushing, protocol, and local testing
Keep the template small
A 400-line template you have not read in six months is a liability: it slows compilation, hides bugs, and tempts you into pasting a structure you no longer understand. Keep the header short and store real structures as separate files you re-type or paste deliberately.
The rule that matters: never paste a structure you could not re-derive. Debugging a black box under contest pressure is the worst position to be in.
What belongs where
| Tier | Contents | Why |
|---|---|---|
| Always pasted | includes, using, fast I/O, a few typedefs | costs nothing, used every problem |
| Pasted on demand | DSU, segment tree, modint, geometry point | large, and you should know when you need them |
| Looked up | Blossom, link-cut trees, MCMF | rare, and worth reading before using |
Verifying the library
Reference implementations should be tested once, thoroughly, and then trusted. Library Checker exists for exactly this: it has a problem for nearly every standard structure, with strong tests. Verify each snippet the day you write it, not the day you need it.
See also: Contest Workflow · Contest Checklist · Debugging · Data Structure Catalog