Tirsvad
1d35410b8d
Create the Business Case, Stakeholder Analysis (S01 course participant, S02 Udemy coursists, S03 GitHub viewers), Project Plan and the milestone documents MIL-001 (project setup, 6 tasks) and MIL-002 (game implementation, 8 tasks) for the console Blackjack game. Register PP and MIL in the artifact registry, set the PO language to en, and link the synced Gitea milestones in the Gateway Schedule. Refs #1 Refs #2 Refs #3 Refs #4 Refs #5 Refs #6 Refs #7 Refs #8 Refs #9 Refs #10 Refs #11 Refs #12 Refs #13 Refs #14
95 lines
5.1 KiB
Markdown
95 lines
5.1 KiB
Markdown
---
|
|
name: coding-conventions
|
|
description: Programming conventions for writing or reviewing source code — naming, layout, formatting and language idioms — for Python, C, C++, C# and Shell (bash). Use when writing, editing, reviewing or refactoring code in one of those languages, choosing names, setting up a formatter/linter config, or adding conventions for another language. Holds the rules shared by every language and points to a per-language sub-skill.
|
|
---
|
|
|
|
# Coding Conventions
|
|
|
|
One skill for all languages. This file holds what is true in every language;
|
|
everything specific to one language is in a sub-skill that is read only when
|
|
that language is in hand:
|
|
|
|
| Language | Sub-skill | QC checklist |
|
|
| --- | --- | --- |
|
|
| Python | `references/python.md` | `framework/qc/qc-programming-python.md` (`QC-PY-001`) |
|
|
| C | `references/c.md` | `framework/qc/qc-programming-c.md` (`QC-CL-001`) |
|
|
| C++ | `references/cpp.md` | `framework/qc/qc-programming-cpp.md` (`QC-CPP-001`) |
|
|
| C# | `references/csharp.md` | `framework/qc/qc-programming-csharp.md` (`QC-CS-001`) |
|
|
| Shell (bash) | `references/shell.md` | `framework/qc/qc-programming-shell.md` (`QC-SH-001`) |
|
|
|
|
Read the sub-skill for the language you are working in, then write or review
|
|
the code. To review, use the language's QC checklist and record the result as
|
|
an `RC-*` (see the `artifact` skill).
|
|
|
|
## Precondition: a planned task
|
|
|
|
Before writing or editing code under `src/` or `tests/`, name the task row
|
|
(`MIL-NNN`, task N) or the synced issue, and the use case or design artifact
|
|
it implements, or say it is a plain technical task. If you cannot, refuse and
|
|
use the `project-planning` skill instead (rule: `framework/process/plan-first-gate.md`).
|
|
Reviewing code needs no task.
|
|
|
|
## Rules for every language
|
|
|
|
1. **The existing code wins.** In a file or project that already has a
|
|
convention, follow it, even if the sub-skill says otherwise. Do not mix
|
|
styles within a file; do not reformat code you are not changing.
|
|
2. **Naming follows the language, not your habits.** Casing differs per
|
|
language (table below). Never carry one language's casing into another.
|
|
3. **A name says what, not how.** Name by purpose in the domain's language
|
|
(IT Professional English, as the registry's `Languages` section says), not by
|
|
type or implementation (`customer_list`, not `arr2`).
|
|
4. **Length follows scope.** Short names (`i`, `n`) only for tiny scopes;
|
|
wider scope, longer name. No abbreviations except ones the whole domain
|
|
uses (`id`, `url`, `http`).
|
|
5. **Booleans read as a question:** `is_valid`, `has_items`, `can_retry`
|
|
(cased per language). No negated names (`is_not_ready`).
|
|
6. **Functions are verbs, types are nouns.** A function that returns a value
|
|
without side effects may be a noun (`total`, `Total`) where the language
|
|
community does so.
|
|
7. **Formatting is done by the formatter,** not by hand and not in review
|
|
comments. Each sub-skill names the formatter and linter; commit its
|
|
configuration file with the code.
|
|
8. **Comments say why,** never what the code already says. Public APIs get
|
|
the language's documentation-comment form.
|
|
9. **No dead or commented-out code, no unexplained magic numbers.** Name the
|
|
constant.
|
|
10. **Errors are handled or propagated, never swallowed.** Each sub-skill says
|
|
how its language does this.
|
|
|
|
## Casing at a glance
|
|
|
|
| Element | Python | C | C++ | C# |
|
|
| --- | --- | --- | --- | --- |
|
|
| Type / class | `PascalCase` | `snake_case_t` | `PascalCase` | `PascalCase` |
|
|
| Function / method | `snake_case` | `snake_case` | `snake_case` | `PascalCase` |
|
|
| Variable / parameter | `snake_case` | `snake_case` | `snake_case` | `camelCase` |
|
|
| Constant | `UPPER_SNAKE` | `UPPER_SNAKE` | `kPascalCase` | `PascalCase` |
|
|
| Private member | `_leading` | file-scope `static` | `trailing_` | `_camelCase` |
|
|
| Namespace / module | `snake_case` module | `mod_` prefix | `snake_case` | `PascalCase` |
|
|
| File | `snake_case.py` | `snake_case.c/.h` | `snake_case.cpp/.h` | `PascalCase.cs` |
|
|
|
|
The table is a summary; the sub-skill is authoritative. Shell (bash) is not in
|
|
the table: functions and variables are `snake_case`, constants and environment
|
|
variables `UPPER_SNAKE`, files `kebab-case.sh`.
|
|
|
|
## Governance boundary
|
|
|
|
Conventions are **defined and governed** here but **not enforced** by this
|
|
framework: writing a linter or CI job that enforces them is outside the
|
|
framework's scope. The formatter and linter names in each sub-skill are the
|
|
recommended tools, not a pipeline. A new or changed convention follows the
|
|
process in the project's Coding Standards Governance document and is recorded
|
|
in `framework/CHANGELOG.md`. No project data belongs in this skill.
|
|
|
|
## Adding a language
|
|
|
|
1. Add `references/<language>.md` with these sections: Standard base, Naming,
|
|
Formatting, Language rules, Errors, Tests, Tooling.
|
|
2. Add `framework/qc/qc-<language>.md` (`QC-<SHORT>-001`) using the `QC` type
|
|
of the `artifact` skill, tagging every criterion with an ISO/IEC 25010:2023
|
|
characteristic and a Level.
|
|
3. Add the row to the table above, the casing table, and a row for the
|
|
language in `framework/registry/artifact-catalog.md`; note it in
|
|
`framework/CHANGELOG.md`; run `bash framework/scripts/install-skills.sh`.
|