Code and archive conventions

These conventions apply to new work and edits. Preserve historical code and avoid inventing claims about its style, judging status, or complexity.

Paths and naming

Follow each platform's existing conventions in Project structure. Use the original problem ID rather than only its title, preserve its case, and prefer stable ASCII filenames for new files. Maintain compatibility with existing paths containing Chinese characters, spaces, or mixed case, and quote paths in commands.

A problem's default submission file belongs in its platform directory. To retain alternative implementations or unsuccessful attempts, use meaningful suffixes such as _bruteforce, _stress, or _wa, and document their status in comments or companion notes. Avoid ambiguous backup names such as copy or backup.

For drafts missing original problem information, preserve a traceable location and status without guessing their platform. Use git mv for confirmed moves, and check CPH import rules, derived website links, and data snapshots. Keep moves separate from algorithm changes.

Individual solutions

Each submission should compile independently on its target judge, without local absolute paths or private headers outside the repository. Use standard input and output, and remove debugging output and local redirection. Check integer ranges, array capacities, recursion depth, and time and space complexity against the problem limits.

Follow existing indentation for local edits. New files may use four spaces or tabs from the contest template, but should not mix them within a code block. Avoid rewriting historical code solely for formatting. Use UTF-8 for additions and LF line endings in documentation and scripts.

Comments should explain state definitions, loop invariants, boundary handling, and non-obvious transitions. Avoid narrating simple statements line by line. Short contest variable names are acceptable; public template parameters and preconditions must be understandable.

Provenance and validation status

When adding a solution or documenting an older one, use a minimal header like this. Record AC verdicts, submission links, or complexity only when evidence supports them. Mark unknown items as unknown or omit them.

// Problem: https://atcoder.jp/contests/abc231/tasks/abc231_a
// Status: sample-checked
// Checks: input 1000 -> output 10.000000
// Time: O(1), Space: O(1)

Status	Minimum evidence
draft	Unfinished or not yet run
compile-checked	Recorded compiler, standard, and successful compilation
sample-checked	Listed samples executed and compared; this does not establish correctness on all inputs
ac	Accepted verdict from the judge, with a submission link and judging time where available

Git commit time records a repository change, not an online judge's evaluation time. Keep those distinct. Historical files without a status header or provenance receipt have unrecorded status.

Sources imported through the archive tools retain their original content. Validation status and provenance live in archive/submissions.json; adding header comments would break verified hashes. Receipts must be checked against actual submission pages and generated by the tools. Never enter an unverified AC verdict manually. When changing imported code, distinguish the new edit from the original submission and correct any integrity claims that no longer apply.

Place longer explanations in a matching .md file beside the source. Include the original problem link, key idea, correctness argument, complexity, and validation record. Link to the original statement for constraints instead of copying it in full.

Templates

For new or changed templates, document purpose, interface, index ranges, initialization, numeric limits, complexity, and dependencies. Use at least one minimal program to cover normal calls and boundaries. A template fragment is not a standalone submission, and an existing filename does not establish implementation stability.

Commit scope

Follow .gitignore for samples, binaries, logs, and local caches. It uses an allowlist with a default ignore rule. Before adding configuration or files in a new language, check git check-ignore -v <path> and allow precise paths as needed. Avoid force-adding the whole repository.

See Contributing for the process and commit format.