# Should I have written tests on basic programming skills?

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?

• The example you give is finding logical errors. Basic syntax will get syntax errors, which the compiler/interpreter should catch. Not so with logical errors. And mixing up = vs == will lead to logical errors, because it almost always evaluates to true - as in , "why yes, this value can be or just has been assigned to that variable". So... test on debugging code. Both syntax errors and logic errors. Add in testing for edge cases, and you are part way on to teaching how to create unit tests :) – ivanivan Jun 1 '18 at 1:26

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.

• Agree about CS-APA and FRQs. We do a bunch of those in class. But they're graded very lightly on syntax. Ex: = and == can be used interchangeably. Braces can generally be omitted if the intent can be determined by indention. – Ryan Nutt May 23 '17 at 21:36
• As a fellow APCS-A teacher I have students keep a written notebook. In this they hand-write sample code as concepts are covered in class. I grade their notebooks every week by walking around the class with a checklist while they are working on their Friday coding project. Super fast and easy to do, and it is very evident who is not progressing, or who is just sloppy. I think the key to this is frequent, regular, formal checking with a consequence (notebooks are 5% of their final grade). – Kapai May 24 '17 at 4:01
• @Kapai Thanks for sharing your practice. I really like that idea for next year. – Peter May 24 '17 at 5:37
• For my HS work we had a very rigorous; Flowchart -> Hand Code -> Enter into IDE & Debug to force us to work on thinking through the problem, attempting it by hand, and then fixing what we b0rked. – AlG May 24 '17 at 18:53

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.

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);
{
}


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

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.

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").

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.

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

• and are thought to be of little value now Depends on who you ask. They're still quite common. (And in some respects I'm not very good at them, even though I'm a rather proficient coder). – Draco18s no longer trusts SE Jun 23 '17 at 16:34
• Well, they're good in that the people who refuse to do them are worth interviewing... – Sean Houlihane Jun 23 '17 at 16:36
• Not necessarily there either. People can refuse because they know that the measure of the test is pointless or they might refuse because they know that they aren't any good at programming. In either case the result is equivalent to, "This scores Banana out of Ten." – Draco18s no longer trusts SE Jun 23 '17 at 16:51

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.

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.

• At the times, the feedback loop (punch-cards / submit / get the result) was so slow that tracing examples by hand was seen as a viable option for the debugging, even for complicated programs. And trying the modified version. Took lot of time, but was faster than wasting the next compilation batch for remaining stupid mistakes. – Michel Billaud May 28 '18 at 9:19
• "At the risk of sounding like the old guy reminiscing about the good old days that were not really so good" => Hand check the program before running it. blogs.msdn.microsoft.com/alfredth/2007/06/22/… – Michel Billaud May 28 '18 at 9:23
• @MichelBillaud, yes, how painful it was. Though I also seem to remember that desk checking was something we recommended to students, but didn't actually do ourselves. We were infallible, of course, or thought it to be so. ;-) – Buffy May 29 '18 at 12:50
• Actually, unit test does the job – Michel Billaud May 29 '18 at 16:42