<p>There are two things you can do (among others). </p>

<ul>
<li>Fixer Upper: Having students finish or repair a program that you create is a useful early exercise. In particular, you can give them a program larger than they would be expected to write themselves. It needs to have excellent design/coding. But you have either removed or carefully broken a few parts before you give it to them. The errors introduced can be quite simple (missing punctuation) or more complex. Their task is to repair it. </li>
</ul>

<p>The students get to (a) read code (b) see good design (c) interpret compiler diagnostics (d) grapple with structure - assuming the program has some length. </p>

<p>This idea is discussed in the book <a href="https://smile.amazon.com/Pedagogical-Patterns-Educators-Joseph-Bergin/dp/1479171824/" rel="nofollow noreferrer">Pedagogical Patterns: Advice for Educators</a>, where it is called "Fixer Upper". You can use it for program errors other than simple syntax errors. </p>

<ul>
<li>Use an IDE that highlights syntax problems. This is actually my main advice. Syntax errors can now be diagnosed by tools so that a programmer needn't spend a lot of mental effort on them; effort that is better spent elsewhere. </li>
</ul>

<p>There are many such editors, from the simple, say that built in to <a href="http://greenfoot.org" rel="nofollow noreferrer">Greenfoot</a>, to the sophisticated, say <a href="http://eclipse.org" rel="nofollow noreferrer">Eclipse</a>.  Even with forty-five years of programming experience I wouldn't want to have to write with any lesser sort of tools. </p>

<p>Note that in natural language we often make syntax errors (in speaking and writing) and that seldom has an impact on transmission of meaning. Computer languages are picky, of course, but the tools will help you learn. If you correct a lot of errors you will get better at not making them, most likely. </p>

<p>At some point, of course, you would like students to be able to find/fix errors on printouts, or even figure out obfuscated code. But that doesn't need to be their first task. They have enough to do already. So make life easy when you can. </p>

<hr>

<p>However, if you are going to use a sophisticated editor with novices there are some tricks to get them started. Staring at a blank computer screen is even less productive than searching for syntax errors. To do this requires a lab of some sort and some time for a demonstration. To do the demo I suggest that you pair the students so that there is one student at each computer. They can help one another - and should be encouraged to swap control of the keyboard back and forth as you go. The demo has two parts. </p>

<p>First, you install the software on your own machine whose screen is projected for the class to see. They follow along. Some students will get it faster than others, which is the reason for pairing. Without it you will be stopped too often to help individuals. If you have a assistant who can go around to solve problems as you go, all the better. If the software is already installed on lab machines and they don't need to install it on their own, you still need to do some of this step to get them used to the UI. </p>

<p>Second, you develop some simple program on your machine, demonstrating simple features that they need immediately. In particular, show them what happens when <em>you</em> make a syntax error. Show them how to recognize the highlighting or whatever the system uses. In this part of the demo it is more fruitful if the students don't work along with you step by step. But you do a bit while they watch and ask questions. Then they spend some time, in their pairs, catching up. </p>

<hr>

<p>Finally, I note that languages with static typing (Java) have tools that can, in principle, provide better guidance than those with dynamic typing (Python, Ruby). Of course, Java has a lot of opportunities for syntax errors, too. </p>

CC BY-SA 3.0
2017-09-04T18:49:39.143Z
2017-09-04T19:17:49.517Z
2017-09-04T19:17:49.517Z
Buffy
<p>This is a big reason I like to teach about HTML and web sites before getting into a full-fledged programming language.  I require my students to use the HTML 5 validator to validate their pages.  From this, they learn about reading error messages, and they learn how to stamp out errors.  <a href="http://www2.ncssm.edu/~morrison/currentClasses/specs/replicateMe.php" rel="nofollow noreferrer">This</a> project specifies the student must use proper HTML.  They can get 100% if they use the validator and extirpate all error messages.  </p>

<p>HTML error messages are far easier to read than those arising from programming languages.  As a second benefit, we discuss HTML and the document tree.  We then relate this tree structure to the tree structure of a file system.</p>

CC BY-SA 3.0
2017-09-06T12:41:33.250Z
2017-09-06T12:41:33.250Z
ncmathsadist
<p>I have not done Java, but I will draw from my experience teaching C #, jQuery and an entire collection of platforms I have worked on. </p>

<ol>
<li>Rely on intellisense. Lot of students, for reasons that defy logic, don't trust the intelligence. Me though, I insist my students to wait (it takes a few seconds, sometimes more depending on how fast the machine is) for the intelligence to prompt things. This guideline alone saves a truck load of syntax mistakes.</li>
</ol>

<p><a href="https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx" rel="nofollow noreferrer">Intellisense</a> aka <a href="http://en.wikipedia.org/wiki/Intelligent_code_completion" rel="nofollow noreferrer">Intelligent code completion</a>, for those who came late, is a feature available in most modern IDEs (visual studio, eclipse. Xcode, Android Studio) where, like when you do bing search, the words are automatically prompted for you. Things like reserved words ( for example int, main and all that) and function declarations, library names and anything else that is fixed. You use this, you NEVER get a syntax error. Easy peasy.</p>

<ol start="2">
<li>Dont ignore warnings. Another classic beginner problem. Ignoring warnings. Unless it is really something that is trivial (a declared variable that is not used) I insist on fixing the warning, as that could potentially be a syntax issue, or something that is being used properly. </li>
</ol>

<p>I would go further, ask them to use the Camel Case (any one of its variations) but since not all will end up developers in your course, perhaps this is not useful.</p>

<p>I emphasise preemptively solving the problem of syntax errors here. If syntax errors have already happened, I guess, you fix them line by line. Alternatively, simply start from scratch, follow the above 2 guidelines is what I tell my students.</p>

CC BY-SA 3.0
2017-09-04T19:00:58.503Z
Perhaps you can say a bit more about _Intellisense_. Not everyone will be familiar with it.
Buffy
CC BY-SA 3.0
2017-09-05T04:02:17.460Z
affirmative and executed.
Jay
CC BY-SA 3.0
2017-09-04T18:25:07.360Z
2017-09-05T04:02:03.460Z
2017-09-05T04:02:03.460Z
Jay
<p>I would start by showing them a few natural language examples, where changing one letter in a sentence completely changes the meaning, perhaps into nonsense.  Most computer languages respond similarly to almost any syntax change.</p>

<p>Then show students program lines with correct and incorrect syntax (of typical mistakes, perhaps taken from previous sessions of the same course), and the corresponding error message(s), and/or incorrect/unanticipated run results.  Quiz questions to test this might be, given a line of incorrect syntax, what is the corresponding error message (or bogus result) and a possible correction.</p>

<p>The important idea is to help students form a mental connection between changes in syntax and changes in (IDE/compiler/interpreter/runtime/etc.) behavior.</p>

CC BY-SA 3.0
2017-09-04T21:39:14.653Z
2017-09-04T21:39:14.653Z
hotpaw2
<p>Our college has a course entitled "Introduction To Programming", although I often tell the students that the real title should be "Introduction to Programming... for non-majors... who have never programmed before" (some people will take this course, decide they like it, and go on to major in Computer Science / Software Engineering / etc., but there's no expectation that any particular student will do so).</p>

<p>Given that there's no expectation of prior programming knowledge, we spend some time (in class, on homework assignments, etc) teaching students how to find and fix syntax errors in programs (both theirs, and instructor-provided programs).  (We're using traditional, textual programming languages like Java / JavaScript, and NOT visual languages like Blockly, etc)</p>

<p><strong>My question:</strong> What techniques, exercises, approaches (etc) have you used to help students learn to deal with syntax errors?  What are the pros &amp; cons of your approach?  </p>

CC BY-SA 3.0
2017-09-05T09:31:14.770Z
With the exception of the last paragraph, the question would be better with the “etc”s removed. They read as “and the other things I am thinking”. The one in the last paragraph reads “and any thing else you can think of”, so this is ok.
ctrl-alt-delor
<syntax><cs0>
How to teach beginning students how to find and fix syntax errors?
# How to teach beginning students how to find and fix syntax errors?

(Asked by: username_0 on 2017-09-04)

Our college has a course entitled "Introduction To Programming", although I often tell the students that the real title should be "Introduction to Programming... for non-majors... who have never programmed before" (some people will take this course, decide they like it, and go on to major in Computer Science / Software Engineering / etc., but there's no expectation that any particular student will do so).

Given that there's no expectation of prior programming knowledge, we spend some time (in class, on homework assignments, etc) teaching students how to find and fix syntax errors in programs (both theirs, and instructor-provided programs). (We're using traditional, textual programming languages like Java / JavaScript, and NOT visual languages like Blockly, etc)

**My question:** What techniques, exercises, approaches (etc) have you used to help students learn to deal with syntax errors? What are the pros & cons of your approach?

**Tags:** syntax, cs0

> **Comments:**
> **username_1**: With the exception of the last paragraph, the question would be better with the “etc”s removed. They read as “and the other things I am thinking”. The one in the last paragraph reads “and any thing else you can think of”, so this is ok.  

---

## 4 answers

### Answer by username_5 on 2017-09-04. Score: 3

I would start by showing them a few natural language examples, where changing one letter in a sentence completely changes the meaning, perhaps into nonsense. Most computer languages respond similarly to almost any syntax change.

Then show students program lines with correct and incorrect syntax (of typical mistakes, perhaps taken from previous sessions of the same course), and the corresponding error message(s), and/or incorrect/unanticipated run results. Quiz questions to test this might be, given a line of incorrect syntax, what is the corresponding error message (or bogus result) and a possible correction.

The important idea is to help students form a mental connection between changes in syntax and changes in (IDE/compiler/interpreter/runtime/etc.) behavior.


---

### Answer by username_2 on 2017-09-04. Score: 1

There are two things you can do (among others).

* Fixer Upper: Having students finish or repair a program that you create is a useful early exercise. In particular, you can give them a program larger than they would be expected to write themselves. It needs to have excellent design/coding. But you have either removed or carefully broken a few parts before you give it to them. The errors introduced can be quite simple (missing punctuation) or more complex. Their task is to repair it.

The students get to (a) read code (b) see good design (c) interpret compiler diagnostics (d) grapple with structure - assuming the program has some length.

This idea is discussed in the book [Pedagogical Patterns: Advice for Educators](https://smile.amazon.com/Pedagogical-Patterns-Educators-Joseph-Bergin/dp/1479171824/), where it is called "Fixer Upper". You can use it for program errors other than simple syntax errors.

* Use an IDE that highlights syntax problems. This is actually my main advice. Syntax errors can now be diagnosed by tools so that a programmer needn't spend a lot of mental effort on them; effort that is better spent elsewhere.

There are many such editors, from the simple, say that built in to [Greenfoot](http://greenfoot.org), to the sophisticated, say [Eclipse](http://eclipse.org). Even with forty-five years of programming experience I wouldn't want to have to write with any lesser sort of tools.

Note that in natural language we often make syntax errors (in speaking and writing) and that seldom has an impact on transmission of meaning. Computer languages are picky, of course, but the tools will help you learn. If you correct a lot of errors you will get better at not making them, most likely.

At some point, of course, you would like students to be able to find/fix errors on printouts, or even figure out obfuscated code. But that doesn't need to be their first task. They have enough to do already. So make life easy when you can.

---

However, if you are going to use a sophisticated editor with novices there are some tricks to get them started. Staring at a blank computer screen is even less productive than searching for syntax errors. To do this requires a lab of some sort and some time for a demonstration. To do the demo I suggest that you pair the students so that there is one student at each computer. They can help one another - and should be encouraged to swap control of the keyboard back and forth as you go. The demo has two parts.

First, you install the software on your own machine whose screen is projected for the class to see. They follow along. Some students will get it faster than others, which is the reason for pairing. Without it you will be stopped too often to help individuals. If you have a assistant who can go around to solve problems as you go, all the better. If the software is already installed on lab machines and they don't need to install it on their own, you still need to do some of this step to get them used to the UI.

Second, you develop some simple program on your machine, demonstrating simple features that they need immediately. In particular, show them what happens when *you* make a syntax error. Show them how to recognize the highlighting or whatever the system uses. In this part of the demo it is more fruitful if the students don't work along with you step by step. But you do a bit while they watch and ask questions. Then they spend some time, in their pairs, catching up.

---

Finally, I note that languages with static typing (Java) have tools that can, in principle, provide better guidance than those with dynamic typing (Python, Ruby). Of course, Java has a lot of opportunities for syntax errors, too.


---

### Answer by username_3 on 2017-09-06. Score: 0

This is a big reason I like to teach about HTML and web sites before getting into a full-fledged programming language. I require my students to use the HTML 5 validator to validate their pages. From this, they learn about reading error messages, and they learn how to stamp out errors. [This](http://www2.ncssm.edu/~morrison/currentClasses/specs/replicateMe.php) project specifies the student must use proper HTML. They can get 100% if they use the validator and extirpate all error messages.

HTML error messages are far easier to read than those arising from programming languages. As a second benefit, we discuss HTML and the document tree. We then relate this tree structure to the tree structure of a file system.


---

### Answer by username_4 on 2017-09-04. Score: -1

I have not done Java, but I will draw from my experience teaching C #, jQuery and an entire collection of platforms I have worked on.

1. Rely on intellisense. Lot of students, for reasons that defy logic, don't trust the intelligence. Me though, I insist my students to wait (it takes a few seconds, sometimes more depending on how fast the machine is) for the intelligence to prompt things. This guideline alone saves a truck load of syntax mistakes.

[Intellisense](https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx) aka [Intelligent code completion](http://en.wikipedia.org/wiki/Intelligent_code_completion), for those who came late, is a feature available in most modern IDEs (visual studio, eclipse. Xcode, Android Studio) where, like when you do bing search, the words are automatically prompted for you. Things like reserved words ( for example int, main and all that) and function declarations, library names and anything else that is fixed. You use this, you NEVER get a syntax error. Easy peasy.

2. Dont ignore warnings. Another classic beginner problem. Ignoring warnings. Unless it is really something that is trivial (a declared variable that is not used) I insist on fixing the warning, as that could potentially be a syntax issue, or something that is being used properly.

I would go further, ask them to use the Camel Case (any one of its variations) but since not all will end up developers in your course, perhaps this is not useful.

I emphasise preemptively solving the problem of syntax errors here. If syntax errors have already happened, I guess, you fix them line by line. Alternatively, simply start from scratch, follow the above 2 guidelines is what I tell my students.

> **Comments:**
> **username_2**: Perhaps you can say a bit more about _Intellisense_. Not everyone will be familiar with it.  
> **username_4**: affirmative and executed.  

---

