Skip to main content

Section 5.4 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.4.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.

Checkpoint 5.4.2. Inline Coding Exercise, Partial.

Similar to above, but we provide a starting point for the exercise. 
#include <stdio.h>

int main(void)
Answer.
We’re not really sure. But it would begin as follows: 
#include <stdio.h>

int main(void)

Activity 5.4.3. 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>. (There is an empty <tests> element here, designed to test relief for an error this will cause on a Runestone server.)
Answer.
We’re still not really sure.

Checkpoint 5.4.4. 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.
Unit testing can be used to automatically evaluate student work. Unit testing frameworks are available for Python, Java, and C++

Checkpoint 5.4.5. Coding Exercise, with Unit Tests.

Fix the following code so that it always correctly adds two numbers. [Ed. Unit test support is experimental.]
Answer.
We’re not really sure. But it would begin as follows: 
#include <stdio.h>

int main(void)
An activecode exercise can offer extra help to a reader who gets stuck, via Runestone’s CodeTailor feature. A @codetailor attribute adds a “Get Help” button that, on a Runestone server, presents a personalized Parsons problem—the blocks of a correct solution, scrambled for the reader to reassemble, where a block may hold one line of code or several. The value all scrambles a complete solution, while incorrect locks the blocks a reader already has right, so only the wrong ones move. A companion @codetailor-fallback names, by its @xml:id, a Parsons problem elsewhere in this document to present when a personalized problem cannot be generated; without it, generation is always requested. The first exercise below elects all and falls back to a Parsons problem from a later chapter; the second elects incorrect and relies on generation alone.

Checkpoint 5.4.6. Coding Exercise, with CodeTailor Help.

Write a function total that returns the sum of a list of numbers. If you get stuck, use the “Get Help” button to assemble a solution from scrambled blocks.
Solution.
Accumulate the numbers in a running total. 
def total(numbers):
    result = 0
    for n in numbers:
        result = result + n
    return result

Checkpoint 5.4.7. Coding Exercise, CodeTailor Help for Incorrect Blocks.

Write a function largest that returns the greatest number in a nonempty list. Here the “Get Help” button locks the blocks you already have right, so you rearrange only the incorrect ones.
Solution.
Track the greatest value seen so far. 
def largest(numbers):
    result = numbers[0]
    for n in numbers:
        if n > result:
            result = n
    return result

Checkpoint 5.4.8. Java Exercise, with Unit Tests.

Unit tests for Java can be written using junit. 
public class Test1
{
    public static void main(String[] args)
    {
        boolean isRaining = true;
        if (isRaining)
        {
            System.out.println("Take an umbrella!");
        }
        System.out.println("Drive carefully");
    }
}

Checkpoint 5.4.9. C++ Exercise, with Unit Tests.

Unit tests for C++ can be written using doctest or catch. Doctest based tests build substantially faster than catch based ones.
In an interactive environment, the tests in this exercise will be made visible, but uneditable, so that in the event of a failed test the student can see exactly what is being tested (Doctest does not report on individual passed tests and the feedback on failed tests generally won’t make sense without the test itself). 
// Complete the function to return the sum of two numbers
int add(int a, int b) {

}
For simple programs, or languages without an available unit testing framework, input-output testing can be done instead. IO testing can only be done on languages that are run on a Runestone server (Java/C/C++/Octave/Python3).

Checkpoint 5.4.10. C++ Exercise, with IO Tests.

Read in an integer n. Print out a n by n square of asterisks. 
#include <iostream>
using namespace std;
int main() {
    int n;
    cin >> n;
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < n; j++) {
            cout << "*";
        }
        cout << endl;
    }
}
PrevTopNext