<!-- Generated from applied-computing-au vic/unit3-4/sat/C07-2026/C07-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
# C07 — Skills in Developing the Software Solution

The Hamilton and Alexandra College · Year 12 · 2026

Study material and grading standard for **VCE Software Development, Unit 4 Outcome 1, Criterion 7** — *Skills in developing the software solution* — for students building their SAT in **Godot / GDScript**.

Each page covers one indicator: the VCE definition, the GDScript conventions, labelled examples — from the shared **Myki fare app** domain and from the projects we studied in class — and the **evidence standard**: what earns each tick and what does not. Your checkpoint and validation feedback is graded against these pages, so what they say *is* the standard.

**Where C7 is assessed:** C7 does not run its own validation. All three indicators are assessed **live in Part B** of the single 100-minute Live Coding Validation, on your comment-stripped copy of the one feature the teacher picks: a **naming audit** (C7-1), writing the **internal documentation from scratch** (C7-2), and adding **input validation** with a test run to show the checks fire (C7-3).

## Foundations

- [Essential Terms](/sd/C07/Essential%20Terms) — the C07 glossary; click a term to expand its definition

## Using these pages for your checkpoint

1. Pick a nominated feature you have built.

2. Walk the lookup table below: for each code, open its page and compare your code against the **Earns the tick** line.

3. Label the exact line (`# C721a — …`), and for every ✍️ code write the actual prose — the label alone earns nothing there.

4. Anything you cannot label yet is your to-do list — each page shows the smallest pattern that earns the tick.

## How the codes work

- **21 skill codes** across **three** indicators: C7-1 naming conventions (5 codes, 25%), C7-2 internal documentation (9 codes, 40%), C7-3 validation techniques (7 codes, 35%).

- **Checkpoint sheet:** three boxes per code — label `C711a` / `C711b` / `C711c` for your first, second and third nominated feature (63 marks).

- **Validation sheet:** one box per code (21 marks), ticked only for skills demonstrated **live** during Part B — naming audit, internal documentation, input validation. Practise doing all three on your own code without notes.

- **✍️ = written evidence required.** These codes need real prose in the comments, not just the label. **All nine C7-2 codes are ✍️** — a student who labels well but writes nothing loses nearly half the criterion.

- **Label as you code.** A skill the marker cannot find earns nothing — put the code in a comment on the line (or block) that shows it. Every example on these pages carries its own label to model exactly this.

**Levels of performance:** Not shown (0) · 1–2 very low · 3–4 low · 5–6 medium · 7–8 high · 9–10 very high.

## Quality qualifiers decide the band

Unlike C6, the C7 descriptors carry **quality words** that matter as much as the code itself:

| Band | C7-2 clarity | C7-3 consistency |
|---|---|---|
| 5–6 | *some issues with clarity* | *some inconsistencies* |
| 7–8 | *minor issues* | *minor inconsistencies* |
| 9–10 | **clear and concise** | **no inconsistencies** |

And C7-2 climbs a verb ladder: **identifies** (1–2) → **outlines** (3–4) → **describes** (5–6) → **explains** (7–8) → **explains all, clear and concise** (9–10).

## Code → page lookup

| Code | Indicator | Level | Skill | ✍️ | Page |
|---|---|---|---|---|---|
| C711 | C7-1 | 1–2 | identifies naming conventions | | [Naming Conventions](/sd/C07/Naming%20Conventions) |
| C712 | C7-2 | 1–2 | identifies functioning | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C713 | C7-3 | 1–2 | identifies input data for validation | | [Validation](/sd/C07/Validation%20Techniques) |
| C721 | C7-1 | 3–4 | applies naming to variables | | [Naming Conventions](/sd/C07/Naming%20Conventions) |
| C722 | C7-2 | 3–4 | outlines functioning | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C723 | C7-3 | 3–4 | existence checking | | [Validation](/sd/C07/Validation%20Techniques) |
| C724 | C7-3 | 3–4 | type checking | | [Validation](/sd/C07/Validation%20Techniques) |
| C725 | C7-3 | 3–4 | range checking | | [Validation](/sd/C07/Validation%20Techniques) |
| C731 | C7-1 | 5–6 | applies naming to interface controls | | [Naming Conventions](/sd/C07/Naming%20Conventions) |
| C732 | C7-2 | 5–6 | describes functionality | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C733 | C7-2 | 5–6 | describes use of data | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C734 | C7-2 | 5–6 | evidence of code maintenance | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C735 | C7-3 | 5–6 | two validation checks | | [Validation](/sd/C07/Validation%20Techniques) |
| C741 | C7-1 | 7–8 | applies naming to code structures | | [Naming Conventions](/sd/C07/Naming%20Conventions) |
| C742 | C7-2 | 7–8 | explains functionality | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C743 | C7-2 | 7–8 | explains use of data | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C744 | C7-2 | 7–8 | explains use of code structures | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C745 | C7-3 | 7–8 | all three validation checks | | [Validation](/sd/C07/Validation%20Techniques) |
| C751 | C7-1 | 9–10 | applies naming to ALL solution elements | | [Naming Conventions](/sd/C07/Naming%20Conventions) |
| C752 | C7-2 | 9–10 | explains ALL, clear and concise | ✍️ | [Internal Documentation](/sd/C07/Internal%20Documentation) |
| C753 | C7-3 | 9–10 | validates ALL input data, reasonableness and completeness | ✍️ | [Validation](/sd/C07/Validation%20Techniques) |

## C6 → C7 synergy

The reasoning comments C6 already asked for (C629/C638/C645/C658 — *why this type / structure / source*) are **also C7-2 evidence**: they describe and explain your use of data. Good internal documentation earns marks on both criteria at once.

## Example code

Snippets come from two places, and the pages keep both:

- The **Myki fare app** domain (balance, fares, zones, concession, journeys) — minimal made-for-purpose examples.

- **Real code from the projects studied in class**, attributed in the snippet's first comment line: `connect-go-dots`, `tile-matching-game` and `club-ladder` — whose comments and naming are the model this criterion asks for (club-ladder especially).