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?

  • $\begingroup$ 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. $\endgroup$ Commented Sep 5, 2017 at 9:31

5 Answers 5


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.


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, 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, to the sophisticated, say Eclipse. 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.


I teach my students to stick to two rules, which help with finding syntax errors and logical flaws:

  1. Develop iteratively. Write a small part of the program; then test it.
  2. When you get an error, break the last piece added up in different pieces and test them one by one. In the future, write smaller parts of code.

Of course, rule 1 is mostly helpful with absolute beginners; it slows down experienced programmers. But for those rule 2 still applies: work the problem down to a Minimal Working Example (MWE). That allows them to ask a concrete, well-scoped questions to their TA (or Stack Overflow).

These two rules make sure that the student has a good idea of where in the code their problem is. And then, that part needs to be read very closely to spot syntax (or logic, ...) errors.

This mantra needs to be repeated over and over again. In my experience, students tend to think top-down and start working on the main logic without first building the basic blocks. That makes it impossible to test the program until it is entirely finished. By then, syntax errors (or really any kind of error) are hard to find. The initial strategy to break up the main logic is good, but then they should take a step back, think about the basic building blocks they are going to need, develop those (when in pairs/groups, this is a good point to divide the work) and test them.

It takes a lot of effort and experience from the TAs to encourage students to read these rules. Often, students come to me with a syntax error without first trying to break down the problem (rule 2). An experienced user of the language immediately sees the error. It is tempting, especially when the lab is busy, to just tell the student what he needs to change. However, that does not really help him any further. You need to actually take the time to sit with the student and perform rule 2 together, until the student spots the mistake himself. Then he will learn the art of debugging.


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


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

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

  • $\begingroup$ Perhaps you can say a bit more about Intellisense. Not everyone will be familiar with it. $\endgroup$
    – Buffy
    Commented Sep 4, 2017 at 19:00
  • $\begingroup$ affirmative and executed. $\endgroup$
    – Jay
    Commented Sep 5, 2017 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.