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

CC BY-SA 3.0
2017-05-23T20:39:36.850Z
2017-05-24T16:33:51.440Z
2017-05-24T16:33:51.440Z
hotpaw2
<p>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...</p>

CC BY-SA 3.0
2017-06-23T16:34:30.817Z
*`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
CC BY-SA 3.0
2017-06-23T16:36:04.023Z
Well, they're good in that the people who refuse to do them are worth interviewing...
Sean Houlihane
CC BY-SA 3.0
2017-06-23T16:51:01.813Z
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
CC BY-SA 3.0
2017-05-23T20:29:02.243Z
2017-05-23T20:29:02.243Z
Sean Houlihane
<p>I first programmed (FORTRAN IV) in 1972. At the time, the main program "editor" was a <a href="https://en.wikipedia.org/wiki/Keypunch#IBM_029_Card_Punch" rel="nofollow noreferrer">key punch machine</a> that punched 80 column cards. You <em>assembled</em> [1] a deck with your program and certain <em>control cards</em>, possibly even including a copy of the Fortran Compiler into a <em>deck</em> 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. </p>

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

<p>As you can imagine, getting the syntax correct the first time was extremely important. </p>

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

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

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

<p>The <a href="https://cseducators.stackexchange.com/a/96/1293">answer here from Peter</a> 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. </p>

<p><strong>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.</strong></p>

<p>If you want them to <em>really learn</em> 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. </p>

<hr>

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

CC BY-SA 4.0
2018-05-28T09:19:05.673Z
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
CC BY-SA 4.0
2018-05-28T09:23:04.330Z
"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. https://blogs.msdn.microsoft.com/alfredth/2007/06/22/programming-proverbs-21-hand-check-the-program-before-running-it/
Michel Billaud
CC BY-SA 4.0
2018-05-29T12:50:31.123Z
@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
CC BY-SA 4.0
2018-05-29T16:42:27.380Z
Actually, unit test does the job
Michel Billaud
CC BY-SA 4.0
2018-05-27T22:52:26.933Z
2018-05-27T22:52:26.933Z
Buffy
<p>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.</p>

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

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

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

CC BY-SA 3.0
2017-05-23T21:36:55.597Z
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
CC BY-SA 3.0
2017-05-24T04:01:10.357Z
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
CC BY-SA 3.0
2017-05-24T05:37:21.243Z
@Kapai Thanks for sharing your practice. I really like that idea for next year.
Peter
CC BY-SA 3.0
2017-05-24T18:53:13.170Z
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
CC BY-SA 3.0
2017-05-23T20:46:28.303Z
2017-05-23T20:53:12.800Z
2017-05-23T20:53:12.800Z
Peter
<p>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 <code>≤</code> instead of <code>&lt;=</code> or the words <code>AND</code>/<code>OR</code> instead of <code>&amp;&amp;</code>/<code>||</code>.</p>

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

CC BY-SA 3.0
2017-06-24T14:36:54.137Z
Hi Derek! Welcome to [cseducators.se]! I hope I see you around more, asking and answering.
thesecretmaster
CC BY-SA 3.0
2017-06-24T14:14:47.857Z
2017-06-24T14:16:54.543Z
2017-06-24T14:16:54.543Z
Derek Miller
<blockquote>
  <p>Is there a better way?</p>
</blockquote>

<p>Consider using an authentic activity that both exercises and motivates the learning.</p>

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

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

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

<pre><code>while(invitations.size() &lt; numberOfAttendees);
{
    invitations.add(customInvite());
}
</code></pre>

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

CC BY-SA 3.0
2017-05-23T23:01:05.287Z
2017-05-23T23:01:05.287Z
Joat
<p>Seems like an objective test early in the year over syntax is a really good way to run off rookies. </p>

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

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

CC BY-SA 3.0
2017-05-23T20:26:13.307Z
2017-05-23T20:26:13.307Z
Ryan Nutt
<p>After reading the answers here I'm left thinking...</p>

<p>What about doing classroom code review?</p>

<p>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 <em>yet again,</em> 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.</p>

<p>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, <code>return i&gt;0?list[i]:null</code>? I've never seen this before").</p>

CC BY-SA 3.0
2017-06-23T16:43:28.733Z
2017-06-23T16:43:28.733Z
Draco18s no longer trusts SE
<p>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.</p>

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

CC BY-SA 3.0
2017-05-23T20:20:18.400Z
2017-05-23T20:20:18.400Z
thesecretmaster
<p>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 <code>=</code> instead of <code>==</code>, this will slow down coding a lot, so it needs to be avoided as much as possible. </p>

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

<p>Will this be effective? Is there a better way?</p>

CC BY-SA 4.0
2018-06-01T01:26:59.703Z
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
<best-practice><grading><syntax><assessment>
Should I have written tests on basic programming skills?
# Should I have written tests on basic programming skills?

(Asked by: username_0 on 2017-05-23)

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?

**Tags:** best-practice, grading, syntax, assessment

> **Comments:**
> **username_1**: 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 :)  

---

## 9 answers

### Answer by username_7 on 2017-05-23. Score: 11

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.

> **Comments:**
> **username_8**: 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.  
> **username_9**: 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).  
> **username_7**: @username_9 Thanks for sharing your practice. I really like that idea for next year.  
> **username_10**: 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.  

---

### Answer by username_11 on 2017-06-24. Score: 6

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.

> **Comments:**
> **username_12**: Hi Derek! Welcome to [cseducators.se]! I hope I see you around more, asking and answering.  

---

### Answer by username_13 on 2017-05-23. Score: 4

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 by username_8 on 2017-05-23. Score: 3

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 by username_4 on 2017-06-23. Score: 3

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 by username_12 on 2017-05-23. Score: 2

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 by username_2 on 2017-05-23. Score: 1

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 by username_3 on 2017-05-23. Score: 1

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

> **Comments:**
> **username_4**: *`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).  
> **username_3**: Well, they're good in that the people who refuse to do them are worth interviewing...  
> **username_4**: 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."  

---

### Answer by username_5 on 2018-05-27. Score: 1

I first programmed (FORTRAN IV) in 1972. At the time, the main program "editor" was a [key punch machine](https://en.wikipedia.org/wiki/Keypunch#IBM_029_Card_Punch) 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 username_7](https://cseducators.stackexchange.com/a/96/1293) 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.

> **Comments:**
> **username_6**: 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.  
> **username_6**: "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. https://blogs.msdn.microsoft.com/alfredth/2007/06/22/programming-proverbs-21-hand-check-the-program-before-running-it/  
> **username_5**: @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. ;-)  
> **username_6**: Actually, unit test does the job  

---

