Commit 36b863
2026-08-12 09:10:36 lisa: Add C07 study pages; regenerate C06 via the shared port script sd/C07: home + Naming Conventions, Internal Documentation, Validation Techniques (21 skill codes), linked from the SD hub. sd/C06 pages regenerated by sat/port-reference-godot-to-wiki.py (marker update; C06-home now generated from the repo README like every other page). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>| sd/C06/C06-home.md .. | |
| @@ 1,11 1,11 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # C06 — Skills in Using the Features of the Programming Language | |
| The Hamilton and Alexandra College · Year 12 · 2026 | |
| - | Criterion 6 is graded from **34 skill codes** (C611–C658) across two indicators: using a range of programming-language features, and using appropriate data types, data structures and data sources. Each page below covers one topic: the VCE definition, the GDScript syntax, 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. |
| + | Study material and grading standard for **VCE Software Development, Unit 4 Outcome 1, Criterion 6** — *Skills in using the features of the programming language* — for students building their SAT in **Godot / GDScript**. |
| - | --- |
| + | Each page covers one topic: the VCE definition, the GDScript syntax, a minimal worked example in the shared **Myki fare app** domain, and the **evidence standard** — what earns each skill-code tick and what does not. Your checkpoint and validation feedback — from your teacher or an AI reviewer — is graded against these pages, so what they say *is* the standard. |
| ## Using these pages for your checkpoint | |
| @@ 19,6 19,8 @@ | |
| ## How the codes work | |
| + | - **34 skill codes** (C611–C658) across two indicators. |
| + | |
| - **Checkpoint sheet:** three boxes per code — label your code `C611a`, `C611b`, `C611c` for your first, second and third nominated feature (102 marks). | |
| - **Validation sheet:** one box per code, ticked only for skills demonstrated **live** during the Live Coding Validation (34 marks) — in the Prove-It's-Yours re-label, the data-layer extension, or a mini-challenge. Practise finding and re-labelling your own code without notes. | |
| @@ 53,12 55,12 @@ | |
| | C624 | 3–4 | conditional operators | [Instructions and Operators](/sd/C06/Instructions%20and%20Operators) | | |
| | C625 | 3–4 | sequence | [Control Structures](/sd/C06/Control%20Structures) | | |
| | C626 | 3–4 | selection | [Control Structures](/sd/C06/Control%20Structures) | | |
| - | | C627 | 3–4 | GUIs | [GUI and Controls](/sd/C06/GUI%20and%20Controls) | |
| + | | C627 | 3–4 | GUIs | [GUI](/sd/C06/GUI%20and%20Controls) | |
| | C628 | 3–4 | data types for local variables | [Local and Global Variables](/sd/C06/Local%20and%20Global%20Variables) | | |
| | C629 | 3–4 | reasoning — why these data types | [Data Types](/sd/C06/Data%20Types) | | |
| | C631 | 5–6 | global variables | [Local and Global Variables](/sd/C06/Local%20and%20Global%20Variables) | | |
| | C632 | 5–6 | iteration / repetition | [Control Structures](/sd/C06/Control%20Structures) | | |
| - | | C633 | 5–6 | relevant GUI controls | [GUI and Controls](/sd/C06/GUI%20and%20Controls) | |
| + | | C633 | 5–6 | relevant GUI controls | [GUI](/sd/C06/GUI%20and%20Controls) | |
| | C634 | 5–6 | data types for global variables | [Local and Global Variables](/sd/C06/Local%20and%20Global%20Variables) | | |
| | C635 | 5–6 | arrays | [Data Structures](/sd/C06/Data%20Structures) | | |
| | C636 | 5–6 | records | [Data Structures](/sd/C06/Data%20Structures) | | |
| @@ 77,12 79,12 @@ | |
| | C657 | 9–10 | range of types, structures and sources | [Data Sources](/sd/C06/Data%20Sources) | | |
| | C658 | 9–10 | reasoning — why all of them | [Data Sources](/sd/C06/Data%20Sources) | | |
| - | Reference-only page with no codes of its own: [Data Type Characteristics](/sd/C06/Data%20Type%20Characteristics) — the input/storage/output table the reasoning codes draw their "why" from. |
| + | Reference-only pages with no codes of their own: [Data Type Characteristics](/sd/C06/Data%20Type%20Characteristics) — the input/storage/output table the reasoning codes draw their "why" from. |
| ## Example code | |
| - | Snippets come from two places, and the pages keep both: |
| + | Snippets use two sources, 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 (e.g. `# connect-go-dots — grid.gd`): `connect-go-dots`, `tile-matching-game` and `club-ladder` — plus *non-examples* showing what does not earn a tick (engine methods, engine inheritance). Also worth reading: `dodge-the-creeps`. |
| + | - **Real code from the projects studied in class**, attributed in the snippet's first comment line (e.g. `# connect-go-dots — grid.gd`). So far: `connect-go-dots` (instructions, sequence, iteration, GUI and controls, autoload global), `tile-matching-game` (operators, selection, a real `while`, data types, typed arrays, records, CSV source, full functions and methods, classes and objects) and `club-ladder` (`match`, class-as-record, direct `.new()`, XML read *and* write, `res://` vs `user://`, model design reasoning) — plus *non-examples* for engine methods and engine inheritance. Also worth reading: `dodge-the-creeps` (GUI, signals). |
| sd/C06/Control Structures.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Control Structures — GDScript | |
| sd/C06/Data Sources.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Data Sources — GDScript | |
| *VCE scope only. The study design names exactly three data sources: **plain text (TXT), delimited (CSV) and XML files**. JSON, databases (SQLite), REST APIs and Godot's own `.tres`/`.res` resources are **out of scope** — they do not earn source codes, however natural they feel in Godot.* | |
| sd/C06/Data Structures.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Data Structures — GDScript | |
| sd/C06/Data Type Characteristics.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Table 5.1 Characteristics of Data Types and Structures | |
| *Language-agnostic — this table applies unchanged to Godot.* | |
| sd/C06/Data Types.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Data Types — GDScript | |
| sd/C06/Functions and Methods.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Functions and Methods — GDScript | |
| sd/C06/GUI and Controls.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # GUI — Godot Control Nodes | |
| sd/C06/Instructions and Operators.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Instructions and Operators — GDScript | |
| sd/C06/Local and Global Variables.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # Local and Global Variables — GDScript | |
| sd/C06/OOP Concepts.md .. | |
| @@ 1,4 1,4 @@ | |
| - | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot — do not hand-edit; re-run the port. --> |
| + | <!-- Generated from applied-computing-au vic/unit3-4/sat/C06-2026/C06-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
| # OOP Concepts — GDScript | |
| /dev/null .. sd/C07/C07-home.md | |
| @@ 0,0 1,84 @@ | |
| + | <!-- 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). |
| + | |
| + | ## 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). |
| /dev/null .. sd/C07/Internal Documentation.md | |
| @@ 0,0 1,157 @@ | |
| + | <!-- 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. --> |
| + | # Internal Documentation — GDScript |
| + | |
| + | **Skill codes on this page — all nine are ✍️: written prose required, the label alone earns nothing.** |
| + | |
| + | | Code | Level | Skill | |
| + | |---|---|---| |
| + | | C712 ✍️ | 1–2 | identifies functioning | |
| + | | C722 ✍️ | 3–4 | outlines functioning | |
| + | | C732 ✍️ | 5–6 | describes functionality | |
| + | | C733 ✍️ | 5–6 | describes use of data | |
| + | | C734 ✍️ | 5–6 | evidence of code maintenance | |
| + | | C742 ✍️ | 7–8 | explains functionality | |
| + | | C743 ✍️ | 7–8 | explains use of data | |
| + | | C744 ✍️ | 7–8 | explains use of code structures | |
| + | | C752 ✍️ | 9–10 | explains ALL, clear and concise | |
| + | |
| + | **Definition.** *Internal documentation:* notes and code comments contained within source code that describe the code. This is the **heaviest indicator** — nine of C7's 21 codes, worth 40% of the criterion — and the whole ladder is a verb climb: **identifies → outlines → describes → explains**, with clarity qualifiers deciding the top bands (*some issues* 5–6 → *minor issues* 7–8 → *clear and concise* 9–10). |
| + | |
| + | **Godot mechanics:** `#` starts a comment; `##` starts a *doc comment* that Godot renders in the editor's help and hover tips — your documentation becomes real, browsable docs (GDScript's equivalent of Python's `pydoc`). Use `##` for file headers and function docs, `#` for inline notes. |
| + | |
| + | **In the validation** Part B you write the internal documentation for the picked feature **from scratch** on the comment-stripped copy — these patterns are what you'll be reproducing from memory. |
| + | |
| + | ## C712 — Identify the functioning |
| + | |
| + | One written line naming what the program (or feature) does: |
| + | |
| + | ```gdscript |
| + | ## C712 — Myki fare app: calculates fares by zone and tracks the card balance. |
| + | ``` |
| + | |
| + | **Earns the tick:** a true sentence about *your* program's purpose. **Doesn't:** a label with no sentence. |
| + | |
| + | ## C722 — Outline the functioning (header comment) |
| + | |
| + | **Definition.** *Header comment:* meaningful comments at the top of a source code file — the file's name, purpose, author and date. |
| + | |
| + | ```gdscript |
| + | ## fare_calculator.gd — Myki fare app # C722 — header comment |
| + | ## Purpose: reads the zone, works out the fare (with the |
| + | ## concession discount), charges the card and updates the display. |
| + | ## Author: <you> Created: 2026-07-28 |
| + | ``` |
| + | |
| + | **Earns the tick:** a header that *outlines the flow* — a reader knows what happens in this file without scrolling. **In club-ladder** every script opens this way: `## The rules. Loads the season, records results, adds and removes teams, and saves after every change.` (`app.gd`). |
| + | |
| + | ## C732 — Describe the functionality |
| + | |
| + | Level 5–6: each function documented with **what it does**: |
| + | |
| + | ```gdscript |
| + | # club-ladder — ladder.gd |
| + | ## Throw away the old rows and build one row per team, in ladder order. # C732 |
| + | func build(teams: Array[Team], win_value: int, draw_value: int) -> void: |
| + | ``` |
| + | |
| + | **Earns the tick:** every function in the picked feature has a doc line that describes its job accurately. |
| + | |
| + | ## C733 — Describe the use of data |
| + | |
| + | What each variable or structure **stores, and what it is used for**: |
| + | |
| + | ```gdscript |
| + | # tile-matching-game — card.gd |
| + | ## Cards with the same pair_id match each other. Two cards in a pair can show |
| + | ## completely different things — matching compares this id, not what is on screen. |
| + | var pair_id := "" # C733 — describes what the data means, not just its type |
| + | ``` |
| + | |
| + | ```gdscript |
| + | var balance: float = 20.00 # C733 — money left on the card, in dollars |
| + | ``` |
| + | |
| + | **Synergy:** the *why-this-type* comments C6 asked for (C629/C638) are C733 evidence too — one comment, marks on both criteria. |
| + | |
| + | ## C734 — Evidence of code maintenance |
| + | |
| + | Comments that record a **fix, change or lesson learned** — proof the code has been maintained, not written once: |
| + | |
| + | ```gdscript |
| + | # tile-matching-game — game.gd |
| + | # The board may have been rebuilt while we were waiting. # C734 — records the bug this guards against |
| + | if is_instance_valid(first_card): |
| + | first_card.flip_down() |
| + | ``` |
| + | |
| + | ```gdscript |
| + | # board.gd |
| + | # add_child() first so the card's @onready variables exist, # C734 — lesson learned, kept for the next reader |
| + | # then fill in what it should show. |
| + | ``` |
| + | |
| + | A dated changelog line also works: `# C734 — 2026-08-01 fixed: fare charged twice when touching on within 2s`. |
| + | |
| + | **Earns the tick:** a comment that could only exist because the code *changed* — a fixed bug, a guarded edge case, a recorded decision. |
| + | |
| + | ## C742 / C743 / C744 — Explain (the why) |
| + | |
| + | Level 7–8 upgrades the verb: not *what*, but **why it works this way**. |
| + | |
| + | **C742 — explains functionality:** |
| + | |
| + | ```gdscript |
| + | # club-ladder — app.gd |
| + | ## Every change goes through here, so there is exactly one place that could # C742 |
| + | ## forget to save — rather than one place per button. |
| + | func refresh() -> void: |
| + | ``` |
| + | |
| + | **C743 — explains use of data:** |
| + | |
| + | ```gdscript |
| + | # club-ladder — team.gd |
| + | ## Games played is worked out, not stored. If we stored it as well we would # C743 |
| + | ## have two places to keep in step, and one day they would disagree. |
| + | func played() -> int: |
| + | return wins + draws + losses |
| + | ``` |
| + | |
| + | **C744 — explains use of code structures:** |
| + | |
| + | ```gdscript |
| + | # club-ladder — team.gd |
| + | ## Points are worked out too, but a Team cannot do it alone: what a win is # C744 |
| + | ## worth is the competition's rule, not the team's. So the caller hands the rule in. |
| + | func points(win_value: int, draw_value: int) -> int: |
| + | ``` |
| + | |
| + | **Earns the tick:** the comment answers *why* — often by naming the alternative you rejected ("if we stored it as well…"). That move is exactly what separates 7–8 from 5–6. |
| + | |
| + | ## C752 — Explain everything, clear and concise |
| + | |
| + | Level 9–10: the whole picked feature documented at explain level — **all** data, **all** code structures — with no noise: |
| + | |
| + | ```gdscript |
| + | age += 1 # add 1 to age ← noise: repeats the code |
| + | age += 1 # C752 — birthday passed; drives the concession re-check below |
| + | ``` |
| + | |
| + | **Earns the tick:** a stranger could maintain the feature from the comments alone, and nothing is written twice or said emptily. *Clear and concise* is the descriptor's own wording — cutting waffle is part of the standard. |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | 1. What does ✍️ mean on a C7-2 code, and what happens if you label but write nothing? |
| + | |
| + | >| ### Answer |
| + | >| Written evidence required — real prose in the comments. A label with no writing earns nothing on all nine C7-2 codes. |
| + | |
| + | 2. Describe vs explain — what is the upgrade? |
| + | |
| + | >| ### Answer |
| + | >| Describing says *what* it does or stores; explaining says *why* it works that way — often by naming the rejected alternative. |
| + | |
| + | 3. Give one thing that counts as evidence of code maintenance (C734). |
| + | |
| + | >| ### Answer |
| + | >| A comment recording a fix, a guarded edge case, or a lesson learned — e.g. "The board may have been rebuilt while we were waiting", or a dated fixed-bug line. |
| /dev/null .. sd/C07/Naming Conventions.md | |
| @@ 0,0 1,145 @@ | |
| + | <!-- 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. --> |
| + | # Naming Conventions — GDScript |
| + | |
| + | **Skill codes on this page** |
| + | |
| + | | Code | Level | Skill | |
| + | |---|---|---| |
| + | | C711 | 1–2 | identifies naming conventions | |
| + | | C721 | 3–4 | applies naming to variables | |
| + | | C731 | 5–6 | applies naming to interface controls | |
| + | | C741 | 7–8 | applies naming to code structures | |
| + | | C751 | 9–10 | applies naming to ALL solution elements | |
| + | |
| + | **Definition.** A *naming convention* is an agreed set of rules by which to name source code elements such as variables, functions, classes, methods and objects. (*Camel case:* each word after the first starts with a capital. *Snake case:* words joined with underscores. *Hungarian notation:* the name encodes purpose and type.) |
| + | |
| + | C7-1 is one ladder: each level applies the convention to **more kinds of element**. In the validation Part B naming audit you state your convention, then fix non-compliant names live. |
| + | |
| + | ## The Godot house convention |
| + | |
| + | | Element | Convention | Example | |
| + | |---|---|---| |
| + | | Variables | `snake_case`, descriptive | `pairs_to_find`, `is_concession` | |
| + | | Constants | `UPPER_SNAKE_CASE` | `DAILY_CAP` | |
| + | | Functions | action-verb `snake_case` | `calculate_fare()` | |
| + | | Classes (`class_name`) | `PascalCase` | `MykiCard` | |
| + | | Nodes / interface controls | `PascalCase`, purpose + control type | `AddButton`, `BalanceLabel` | |
| + | | Signals | `snake_case`, past tense | `fare_calculated` | |
| + | | Files and scenes | `snake_case` | `team_row.gd`, `card.tscn` | |
| + | |
| + | This is the convention every studied project uses — and the one Godot's own style guide recommends. |
| + | |
| + | ## C711 — Identify your convention |
| + | |
| + | Level 1–2 is **stating** the rules, in internal documentation, before applying them: |
| + | |
| + | ```gdscript |
| + | # C711 — naming conventions in this project: |
| + | # variables and functions snake_case; constants UPPER_SNAKE_CASE; |
| + | # classes and nodes PascalCase; signals snake_case, past tense |
| + | ``` |
| + | |
| + | **Earns the tick:** the convention written down where the marker can find it. In the naming audit, this is the sentence you open with. |
| + | |
| + | ## C721 — Variables |
| + | |
| + | Bad names hide meaning; the fix is descriptive `snake_case`: |
| + | |
| + | ```gdscript |
| + | # ✗ before — earns no C721: the names hide the meaning |
| + | var b := 20.00 # what is b? |
| + | var f := 5.30 # what is f? |
| + | ``` |
| + | |
| + | ```gdscript |
| + | var balance: float = 20.00 # C721 — descriptive snake_case |
| + | var fare: float = 5.30 # C721 |
| + | var is_concession := false # C721 — booleans read as yes/no questions |
| + | ``` |
| + | |
| + | **In the studied projects:** `pairs_to_find`, `is_busy`, `flip_back_delay` (tile-matching-game); `points_for_win`, `team_name` (club-ladder). Every boolean starts `is_` — the name reads as the question the code asks. |
| + | |
| + | **Magic numbers are a naming problem too.** A bare `0.5` says nothing; a named constant says everything: |
| + | |
| + | ```gdscript |
| + | # ✗ before — magic number, earns no C721 |
| + | fare = FARE_TABLE[zone] * 0.5 # what is 0.5? |
| + | ``` |
| + | |
| + | ```gdscript |
| + | const CONCESSION_DISCOUNT := 0.5 # C721 — the rule now has a name |
| + | fare = FARE_TABLE[zone] * CONCESSION_DISCOUNT |
| + | ``` |
| + | |
| + | **Earns the tick:** no single-letter names (a loop `i` is fine), booleans as `is_`/`has_` questions, magic numbers replaced by named constants. |
| + | |
| + | ## C731 — Interface controls |
| + | |
| + | Name every Control node **purpose + control type**, in `PascalCase`: |
| + | |
| + | ```text |
| + | NameField (LineEdit) ← what it holds + what it is |
| + | AddButton (Button) |
| + | TitleLabel (Label) |
| + | WarningLabel (Label) |
| + | ``` |
| + | |
| + | Those four are club-ladder's real scene — the name tells you what the control does before you click it. The anti-pattern is Godot's defaults left in place: `Button1`, `LineEdit`, `Label2`. |
| + | |
| + | ```gdscript |
| + | # C731 — controls named purpose + type, so the code reads in English |
| + | %AddButton.pressed.connect(_on_add_pressed) |
| + | name_field.text = "" |
| + | ``` |
| + | |
| + | **Earns the tick:** every control in the picked feature's scene named this way — the audit will open your scene tree and look. |
| + | |
| + | ## C741 — Code structures |
| + | |
| + | Functions get **action verbs**; classes get **PascalCase nouns**: |
| + | |
| + | ```gdscript |
| + | # ✗ before — earns no C741: the name says nothing |
| + | func f(x): # what does f do? |
| + | ``` |
| + | |
| + | ```gdscript |
| + | func calculate_fare(zone: int) -> float: # C741 — verb says what it does |
| + | ``` |
| + | |
| + | ```gdscript |
| + | class_name MykiCard # C741 — PascalCase noun, a clear concept |
| + | ``` |
| + | |
| + | **In the studied projects:** `load_csv()`, `mark_matched()`, `start_new_game()` (tile-matching-game); `class_name Team`, `Season`, `Ladder` (club-ladder) — every function name is a verb phrase, every class a noun. |
| + | |
| + | ## C751 — All solution elements |
| + | |
| + | Level 9–10 extends the convention to **everything that has a name**: signals, scenes, files, autoloads — consistently, throughout. |
| + | |
| + | ```gdscript |
| + | # club-ladder — the convention on every element kind |
| + | signal result_recorded(team: Team, result: String) # C751 — signal: past tense |
| + | signal remove_requested(team: Team) # C751 |
| + | # files: team_row.gd, season.gd — snake_case |
| + | # scenes: main.tscn, team_row.tscn — snake_case |
| + | ``` |
| + | |
| + | **Earns the tick:** open any file in the project and the convention holds — variables, constants, functions, classes, nodes, signals, files. One inconsistent corner (`studentName` beside `student_id`) drops you back. |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | 1. What convention does a Godot node (interface control) use, and what two things should its name say? |
| + | |
| + | >| ### Answer |
| + | >| `PascalCase`, saying purpose + control type — `AddButton`, `BalanceLabel`. |
| + | |
| + | 2. Why is `fare * 0.5` a naming problem, and what is the fix? |
| + | |
| + | >| ### Answer |
| + | >| `0.5` is a magic number — its meaning is invisible. Replace it with a named constant: `CONCESSION_DISCOUNT := 0.5`. |
| + | |
| + | 3. What separates C751 from C741? |
| + | |
| + | >| ### Answer |
| + | >| C741 covers code structures (functions and classes). C751 extends the convention to *every* named element — signals, scenes, files, autoloads — with no inconsistent corners anywhere. |
| /dev/null .. sd/C07/Validation Techniques.md | |
| @@ 0,0 1,147 @@ | |
| + | <!-- 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. --> |
| + | # Validation Techniques — GDScript |
| + | |
| + | **Skill codes on this page** |
| + | |
| + | | Code | Level | Skill | |
| + | |---|---|---| |
| + | | C713 | 1–2 | identifies input data for validation | |
| + | | C723 | 3–4 | existence checking | |
| + | | C724 | 3–4 | type checking | |
| + | | C725 | 3–4 | range checking | |
| + | | C735 | 5–6 | two of the three checks | |
| + | | C745 | 7–8 | all three checks | |
| + | | C753 ✍️ | 9–10 | ALL input data, plus reasonableness and completeness | |
| + | |
| + | **Definition.** *Validation* checks the reasonableness of data inputs, while the program runs. It is not testing (testing happens to the finished program; validation happens to every input, every run). The three named checks: **existence** (was anything entered?), **type** (is it the right kind of value?), **range** (is it within acceptable limits?). |
| + | |
| + | **This ladder is not a checklist.** The individual checks are separate codes only at level 3–4. Above that, single codes stand for the *combination*: C735 = two checks working, C745 = all three, C753 = all inputs plus reasonableness and completeness. Consistency qualifiers decide the band: *some inconsistencies* (5–6) → *minor* (7–8) → *none* (9–10). |
| + | |
| + | **In the validation** Part B you add existence/type/range checks to the picked feature's real inputs, label them as you go, and **run a test to show a check actually fires** — a validation that never catches a bad value is scenery. |
| + | |
| + | ## C713 — Identify the inputs |
| + | |
| + | Level 1–2 is a written list of what needs validating: |
| + | |
| + | ```gdscript |
| + | # C713 — inputs to validate in this feature: |
| + | # team name — NameField (LineEdit), free text |
| + | # zone — ZoneSpinBox (SpinBox), whole number |
| + | # top-up — TopUpField (LineEdit), dollars and cents |
| + | ``` |
| + | |
| + | **Earns the tick:** every user-facing input of the picked feature named. (Choosing constrained controls — a SpinBox can't receive letters — is good design, but the codes below want checks *in code*.) |
| + | |
| + | ## C723 — Existence check |
| + | |
| + | **Definition.** A test to see if a value has been entered as input or not. |
| + | |
| + | ```gdscript |
| + | # club-ladder — app.gd |
| + | func add_team(raw_name: String) -> void: |
| + | var team_name := raw_name.strip_edges() |
| + | if team_name == "": # C723 — existence: nothing entered |
| + | message_label.text = "Type a team name first." |
| + | return |
| + | ``` |
| + | |
| + | Note the real-world details worth copying: `strip_edges()` first (spaces are not a name), and an error message that says **what to do**, not just "invalid". |
| + | |
| + | ## C724 — Type check |
| + | |
| + | **Definition.** A test to see if a value is of the specified data type or structure. |
| + | |
| + | GDScript's idioms — check *before* converting, or the conversion itself is the crash: |
| + | |
| + | ```gdscript |
| + | # C724 — type: is the text actually a number? |
| + | if not $TopUpField.text.is_valid_float(): |
| + | $MessageLabel.text = "Enter an amount in dollars, like 10.50" |
| + | return |
| + | var amount := float($TopUpField.text) |
| + | ``` |
| + | |
| + | `String.is_valid_int()` and `is_valid_float()` are the workhorses. The `is` keyword type-checks objects — real use in tile-matching-game: `if child is Card:` (`board.gd`). |
| + | |
| + | ## C725 — Range check |
| + | |
| + | **Definition.** Tests to see if a value is within a given range of acceptable values. |
| + | |
| + | ```gdscript |
| + | # C725 — range: zones only run 1..3, amounts have a ceiling |
| + | if zone < 1 or zone > MAX_ZONE: |
| + | $MessageLabel.text = "Zone must be 1 to %d" % MAX_ZONE |
| + | return |
| + | if amount <= 0.0 or amount > MAX_TOP_UP: |
| + | $MessageLabel.text = "Top-up must be between $0.01 and $%.2f" % MAX_TOP_UP |
| + | return |
| + | ``` |
| + | |
| + | The limits are **named constants** (`MAX_ZONE`, `MAX_TOP_UP`) — that's C7-1 working for C7-3. Clamping (`maxi(1, column_count)` in club-ladder's `board.gd`) is the accept-and-correct cousin of reject-and-message; for user input, prefer the message — silent correction hides the user's mistake from them. |
| + | |
| + | ## C735 and C745 — The checks working together |
| + | |
| + | One validated input, all three checks, in the order that cannot crash — existence, then type, then range: |
| + | |
| + | ```gdscript |
| + | # C745 — full validation of the top-up amount (existence → type → range) |
| + | func validate_top_up(raw: String) -> String: |
| + | var text := raw.strip_edges() |
| + | if text == "": # C723 — existence |
| + | return "Enter an amount first." |
| + | if not text.is_valid_float(): # C724 — type |
| + | return "Enter a number, like 10.50" |
| + | var amount := float(text) |
| + | if amount <= 0.0 or amount > MAX_TOP_UP: # C725 — range |
| + | return "Amount must be between $0.01 and $%.2f" % MAX_TOP_UP |
| + | return "" # empty string = valid |
| + | ``` |
| + | |
| + | C735 (5–6) is two of these working on real inputs; C745 (7–8) is all three, with at most *minor* inconsistencies. **Error messages are part of the standard** — "Must be between 8 and 72 in length" beats "Invalid input" because it tells the user how to fix it (that Discord message was the class's best-in-show in the Validation Detective activity). |
| + | |
| + | ## C753 — All inputs, plus reasonableness and completeness ✍️ |
| + | |
| + | Level 9–10 widens the lens from single fields to the **whole data set**: |
| + | |
| + | - **All relevant inputs** validated — not just the easy one. |
| + | |
| + | - **Completeness** — is anything missing? Real example: `deck.gd` skips half-empty CSV rows with `if row.size() < 2: continue` (tile-matching-game). |
| + | |
| + | - **Reasonableness** — can these values be true *together*? The model is club-ladder's cross-check: |
| + | |
| + | ```gdscript |
| + | # club-ladder — app.gd |
| + | ## In a competition where teams play each other, one team's win is always # C753 ✍️ |
| + | ## another's loss — so total wins must equal total losses. Worth saying on |
| + | ## screen rather than quietly showing figures that cannot be true. |
| + | func totals_warning() -> String: |
| + | if total_wins == total_losses: |
| + | return "" |
| + | return "Check your data: %d wins recorded, but %d losses." % [total_wins, total_losses] |
| + | ``` |
| + | |
| + | **Earns the tick:** every input covered, a completeness check on incoming records, at least one reasonableness rule that crosses fields — and (✍️) the rule *written down*: work out what rules **your** data has to obey, and say so in a comment. |
| + | |
| + | **Then prove it fires.** End the validation task by entering a bad value and showing the message appear — the package script asks for exactly this test run. |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | 1. Name the three validation checks and their level 3–4 codes. |
| + | |
| + | >| ### Answer |
| + | >| Existence C723, type C724, range C725. |
| + | |
| + | 2. Why are C735 and C745 single codes rather than lists of checks? |
| + | |
| + | >| ### Answer |
| + | >| Above level 3–4 the descriptor rewards the *combination* — two checks working (C735), then all three (C745) — with consistency qualifiers deciding the band. |
| + | |
| + | 3. What makes "Must be between 8 and 72 in length" a better error message than "Invalid input"? |
| + | |
| + | >| ### Answer |
| + | >| It tells the user exactly how to fix the problem — specific beats generic. |
| + | |
| + | 4. Give an example of a reasonableness check (C753). |
| + | |
| + | >| ### Answer |
| + | >| A cross-field rule — e.g. club-ladder's "total wins must equal total losses"; values that are individually fine but cannot be true together. |
| sd/VCE Software Development Hub.md .. | |
| @@ 25,6 25,7 @@ | |
| - [C04 — Skills in Generating Design Ideas and Developing Evaluation Criteria](/sd/C04/C04-home) | |
| - [C05 — Skills in Producing Detailed Designs](/sd/C05/C05-home) | |
| - [C06 — Skills in Using the Features of the Programming Language](/sd/C06/C06-home) | |
| + | - [C07 — Skills in Developing the Software Solution](/sd/C07/C07-home) |
| ## Tools | |