Section 5.3 Coding Exercises
Program listings can be more that just live demonstrations, they can be exercises. The first two also occur in the sample article where they just get a static rendering, if at all.
Checkpoint 5.3.1. Inline Coding Exercise, No Help.
An exercise might ask a reader to write a computer program, that would go here in the <statement>
. But you can also add a <program>
element after a <statement>
. Here we place no code at all, but we do say we want it to be interactive. The purpose is to make it a live coding environment for a version of your output that allows the reader to perhaps submit a solution. The <program>
element is necessary so you can specify a programming language.
In interactive formats, try creating and running a Python program below. Use CodeLens to step through the program.
Checkpoint 5.3.2. Inline Coding Exercise, Partial.
Similar to above, but we provide a starting point for the exercise.
#include <stdio.h>
int main(void)
We're not really sure. But it would begin as follows:
#include <stdio.h>
int main(void)
Activity 5.3.1. Activity Coding Exercise.
Similar to above, but now as a complete Python program inside an <activity>
. This demonstrates the possibility to use any “project-like” block (<project>
, <activity>
, <exploration>
, <investigation>
), but not in the case when structured with <task>
.
Checkpoint 5.3.3. An Exercise with a Static Program.
Similar to above, again, but we place the <program>
element inside the <statement>
, not after it as a peer. This signals that this is not a coding exercise and the program will render static, since it is explicitly labeled as not being interactive.
#include <stdio.h>
int main(void)
Checkpoint 5.3.4. Coding Exercise, with Unit Tests.
Fix the following code so that it always correctly adds two numbers. [Ed. Unit test support is experimental.]
We're not really sure. But it would begin as follows:
#include <stdio.h>
int main(void)