One of our favorite annoyances in programming education is the useless or even stupid exercises we hand out to our students. This is especially annoying given that we, the teachers or educators or whatever we want to be called, claim that the students are lazy when we’re the really lazy ones not bothering to write proper exercises.
So, enough is enough. We must stop writing all these stupid (beyond belief) exercises.
An example of stupid exercise
Take a look at the exercise below. It is a version of typical exercises for students learning how to program in C, but it applies to Java and other languages as well.
Ok, to the exercise:
Write a program that counts the number of ‘i’ in “Liverpool”
Why isn’t that a good exercise? Let’s discuss this shortly:
- Why write a program for this when everyone already knows the answer? Can you honestly say that there exists a student that can’t answer this wothout writing a program? .….the exercise is boring and useless.
- You’re solving a very specific problem with an equally specific program. …the exercise is not general.
We (this blog’s authors) have learnt from experience that there seems to exist a, sort of, catch-all explanation to the existance of exercises (and all other things in programming education) like these. The phrase goess:
It’s a classic!
OME (Oh my Emacs)! How could this possibly be a motivation behind anything? It used to be a classic that the world was flat. Is it still a good explanation? We will tag all our posts dealing with this stupid and ignorant explanation with the tag “classic“. If you ever motivate anything with “it’s a classic” chances are you should remove it.
Towards a better exercise
Ok, if the two of us are so damn good (actually we’re not claiming we’re good but we are claiming that we’re trying) what is our take on this?
We’re not saying that the exercise above is 100% useless. Ok, as it is written above it is probably 99% useless and stinks. But fact is, we believe it serves as a nice starting point for a larger exercise with a progression. Here are some suggestions on what can be done to make the exercise more useful. Let’s turn the exercise into several exercises (in progression):
- Write a program (with a main function) that counts the number of ‘i’ in “Liverpool”
- Put the code doing the count in a separate function.
- Make the function general – any letter in “Liverpool”
- Make the function more general – any letter in any text
- Make the function even more general – any (sub)string in any string
- Make use of existing API functions
- Make the function robust
- Put the function in one file and the main function in another
- Write tests
- Write a function printing out the lines containing the string “liverpool”. This is not general – but a useful start.
- Write a function printing out the lines, in a file, containing any string., using the function above. This is not general enough – still rather useful.
- Write a function printing out the lines, as read from stdin (a stream) or a file, containing any string
Compare the program with the grep command. The student now has her/his own version of the program grep.
Note: in some languages the word function above should be replaced by method.
Why is this so much better?
- the resulting code is more general (and quite useful)
- the code can be reused (since put in a function)
- the code is tested
- the student has implicitly been taught and practiced HOW TO go from a specific problem to a general solution
Extending the exercise even more
We could add even more tasks for the students
- Use a versioning control system (e g git)
- Add automatic build software (e g make, ant, gradle) to control the building/compilation
- Add © notice
- Add license
- Comment the code
- Write API manual (javadoc, doxygen…)
- Check code coverage on our tests
We try hard to avoid exercises like the above in the books we (the authors behind this blog) are writing:
The books come together with videos:
The books and videos are public and licensed under a free license so feel free to use.