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)