## Section5.3Coding 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.

### Checkpoint5.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.

Hint.
We didn't really ask you to do anything.

### Checkpoint5.3.2.Inline Coding Exercise, Partial.

Similar to above, but we provide a starting point for the exercise.

We're not really sure. But it would begin as follows:

#include <stdio.h>

int main(void)


### Activity5.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>.

We're still not really sure.

### Checkpoint5.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)

Solution.
We're not really sure. Still.

### Checkpoint5.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.]

#include <stdio.h>