Should I have written tests on basic programming skills?

Question

When making more complex programs, it is natural that one needs to run the program to see whether things work and fixing bugs. However, if one makes a lot of mistakes in basic programming, e.g. writing = instead of ==, this will slow down coding a lot, so it needs to be avoided as much as possible.

A possible solution to make students learn the basic syntax very well is to have a written test where students need to make small programs that only use basic syntax. Therefore, students need to learn to do these things right the first time, and also know the basic syntax very well.

Will this be effective? Is there a better way?

Answer 1

As a tool for differentiation, writing out code by hand is absolutely worthwhile. I taught this year in a classroom with whiteboard top desks, and students loved a) getting to writing on their desks (even being encouraged to) while b) learning syntax through multiple modalities. What might catch a student's eye or get instilled in her memory through handwriting is not the same as what she might see in her code in an IDE.

On a pragmatic level, the AP CS A Exam requires students to answer free response questions, so it is essential that they be prepared for this task. I would be doing them a disservice to not require some form of written examination.

That being said, the extent to which you grade this might be the determining factor in its success. As a formative assessment of syntax and of logical thinking, it works great, but again, unless its specific exam (or interview) preparation, it seems less effective or worthwhile.

As noted above, students have to learn how to debug by reading and analyzing error messages. Nonetheless, I don't believe it's so much an either/or here. Use the handwritten assessments to inform instruction and re-teaching and to teach and reinforce concepts in a differentiated manner.

Answer 2

I think having kids write code by hand can be incredibly worthwhile, but be careful of how you assess it. I wouldn't take points off for mistakes that would be easily caught by a compiler such as a missing semicolon or mixing up length and size. I also wouldn't take points off for mistakes students might make when writing code by hand that show they know what they're doing such as using ≤ instead of <= or the words AND/OR instead of &&/||.

With that being said, if you are trying to see if your students understand a basic concept of algorithm, having them write a short segment of code by hand can really help show their true understanding.

Answer 3

Is there a better way?

Consider using an authentic activity that both exercises and motivates the learning.

For example, often the author of code has difficulty finding and repairing errors in the code. You can ask learners to help identify and fix errors in code, provided by you, that is "close" but not quite correct.

The presence of some errors may be readily disclosed by the compiler; but even those may have error messages that point to lines other than where the actual errors exist. Students then need to fix the errors appropriately.

Other errors may pass syntactic checks but produce unintended behavior; such as this inadvertent "empty statement" body of a Java loop.

while(invitations.size() < numberOfAttendees);
{
    invitations.add(customInvite());
}

This guided learning approach also helps improve the likelihood that all students gain experience with the specific concepts that you intend them to.

Answer 4

Seems like an objective test early in the year over syntax is a really good way to run off rookies.

If your kids write enough code, they'll pick up the syntax. After forgetting a semicolon for the 20th time, you start to remember. Trace enough code with = vs == and you'll figure out what's going on.

It's the same way experienced coders pick up new languages. When I first started with Python I would forget to indent or forget colons at the end of loops. Made the same mistake a few times and got used to the syntax.

Answer 5

After reading the answers here I'm left thinking...

What about doing classroom code review?

That is, have the students take the assignment they've completed, print it out, hand it to someone else, then have the students review the code they now have in front of them. When everything thinks they're done, have them switch papers yet again, getting a third set of eyes on things (one coder, two reviewers). Each reviewer would write their name on it as having reviewed it as well.

I hear tales of how marvelous code review is, but I've never had to participate on it in any sort of official setting (i.e. for a job, as a classroom assignment...) but I think this would be a good way to introduce the concept. It's often hard to spot mistakes in one's own code, so having to look for errors in someone else's tends to be easier, as well as letting people see alternative approaches to problems ("What's this syntax here, return i>0?list[i]:null? I've never seen this before").

Answer 6

I think that you could achieve your intended goal more easily simply by waiting. People naturally learn from their mistakes and I think that the wrong equals or no semicolon at the end of a line will stop fairly quickly.

As for written assessments, I think that it is next to useless to have a written syntax quiz to catch typographical errors and simple mistakes like these. Learning to catch these mistakes from error messages is almost as important as not making the mistakes in the first place. It's a lesson in how to read an error message as an added bonus.

Answer 7

You run the risk here of unduly penalising or discouraging students who have dyslexia or other issues which cause them to do badly with this type of trivial test. This sounds a little like the sort of tests that used to be used in job interviews, and are thought to be of little value now...

Answer 8

Some syntax (and symnantic) errors can produce apparently runnable programs that on casual testing even appear to be correct. At a certain level, it may be useful to quiz students to see if they can produce syntax (one to maybe 3 or 4 LOC) that is correct by inspection in these areas.

Answer 9

I first programmed (FORTRAN IV) in 1972. At the time, the main program "editor" was a key punch machine that punched 80 column cards. You assembled [1] a deck with your program and certain control cards, possibly even including a copy of the Fortran Compiler into a deck and you submitted your deck at a window to another person. In a small shop, that person might be the operator and the computer might even be visible somewhere behind the operator - through a window, as computers were noisy and had to be enclosed. Twenty four hours later, you picked up the results at a window.

If there was any error in your program (or elsewhere in the deck), what you got was a failure report and went back to the keypunch to correct it. When done, you started another twenty four hour cycle.

As you can imagine, getting the syntax correct the first time was extremely important.

Now, I program using Eclipse. The system is so efficient that it finds and highlights my syntax errors as I make them. It also finds and maybe corrects lexical (spelling) errors. It completes statement blocks and indents as I go.

There are two lessons here. One is that "getting the syntax right the first time" was much more critical then than now. But also, Eclipse error highlighting and correction actually teaches the student over time not to make the mistakes that are the least important of all. Semantic and intent mistakes are what we need to focus on, and what the teaching (and grading) should focus on, not the kinds of things that tools like eclipse can (a) find/correct and (b) teach us incrementally.

It is useful to be able to write code by hand. Sometimes you are on a bus and need to capture an idea and all you have available is a pencil and paper. But you don't need perfect syntax to capture the idea.

The answer here from Peter notes that in some extremely important tests, students will need to write out code by hand. But the comments currently listed with it also indicate (correctly IMO) that the grading is very gentle on the kinds of things that tools can help us with.

tl;dr: Use good tools in teaching. Focus on the higher level concepts and let the tools correct errors of the formal language as well as help the students see what they should have written.

If you want them to really learn to get the syntax right the first time, use a key punch and 24 hour turnaround. Other forms of abuse might work just as well. But.... well, no, don't do that.

---

[1] The term assembler (or assembly) language comes from this physical construction of a card deck.