SB Coding Exercises

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.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>. (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.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.

🔗

Unit testing can be used to automatically evaluate student work. Unit testing frameworks are available for Python, Java, and C++

🔗

Checkpoint 5.4.4. 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)

🔗

Checkpoint 5.4.5. 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.6. 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.7. 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;
    }
}

🔗

Prev Top Next