Transcript Thesis presentation - Princeton University

Identifying and Correcting Common
Java Programming Errors And
Misconceptions for Introductory
Computer Science Students
Maria Hristova
Ananya Misra
Megan Rutter
Advisor: Prof. Rebecca Mercuri
Bryn Mawr College
May 8th 2002
Overview








Abstract
Introduction
Theoretical Framework
Data Collection And Organization
Finding And Testing Solutions
Example Errors, Solutions And Tests
Sample Run
Conclusion And Future of The Project
Abstract
The Java programming language is currently growing in popularity
within the academic community, and as a result of this, a lot of colleges
are converting their introductory Computer Science courses into Java.
While Java is a very portable and web-compatible language, students
often have a hard time mastering it. There have been some projects that
were aimed to assist students in grasping Java’s conceptual framework,
but many of these involved either simplified Java syntax or preconstructed object modules that distanced students from the process of
coding. Our goal was to design an educational tool that would identify
common Java programming errors and misconceptions and facilitate the
learning process, while making sure that the students interact directly
with their code. In order to achieve our goal, we collected data from
students, professors and members of the Special Interest Group on
Computer Science Education, and compiled a list of errors we wanted our
program to assess. We then created a multiple-pass preprocessor that
detects these errors and suggests corrective action. This presentation
discusses the process we experienced in identifying these errors, designing
and coding solutions, and testing the resulting product.
Introduction


Background
Proposal


Collaborative Research Experience for
Women, Computer Research Association
Existing Projects

DrScheme, BlueJ, Ready, JJ
Theoretical Framework

Pea and Kurland – Cognitive Aspect



Du Boulay – Language-Independent Aspect


Define programming as both a mental mode and a skill like reading
Define the need for a tight bond between an instructional and
programming environment
Defines the five language-independent areas of difficulty and three
kinds of corresponding mistakes
Fleury – Java Aspect


Creates a list of the four most common “student-constructed rules”
in Java
Explores how students understand Java code and what their
misconceptions might be
Pea and Kurland – Cognitive Aspect
Du Boulay – Language-Independent Aspect
Fleury – Java Aspect
Data Collection


Original List of Errors
Professor Surveys



Student Surveys


US News and World Report’s Top 50 Liberal Arts
Colleges 2002
SIGCSE
Swarthmore College
Student Essays

Bryn Mawr and Haverford Colleges
Data Organization


List of Errors Collected
List of Errors Not Included in Final List




Already Identified by Compiler
Don’t Apply to Introductory Students
Can’t Be Checked For
Final List of Errors Considered by Our
Program (on hand-out)
Designing and Testing Solutions

Three Groups of Errors



Syntax - errors in the spelling, punctuation and
order of words in the program
Semantic - errors that are likely to ensue from a
mistaken idea of how the language interprets
certain instructions
Logic - errors that tend to arise from fallacious
thinking by the programmer rather than from
language peculiarities
Single Versus Double Equals Operator

Assignment (=) versus Comparison (==)



if( x = 0) instead of if(x == 0)
int x == 1; instead of int x = 1;
Solution



Looks for the former in if, for and while clauses
Looks for the latter everywhere else
Problem: this solution misinterprets == in boolean
expression outside selection and repetition structures
Incorrect Semicolon in If Statement or For/While Loop

Semi-colon after if, for or while clause


if (x == 0); {<statements>} instead of
if(x == 0) {<statements>}
Solution



Locate if, for and while statements
Possible error if there is a semi-colon directly after
parentheses are balanced
Special case: is the while keyword part of a do-while loop?
Incorrect Semicolon at the End of a Method Header

There should never be a semicolon at the end of a
method header
Void methodName(arguments);{<statements>} should be
Void methodName(arguments){<statements>}


Solution



Search through code for method headers
If a method header is found, make sure there is not a
semicolon before the opening curly bracket
If a semicolon is found return an error
Invoking Methods With Wrong Arguments

Method call parameter types must match method definition
parameter types


Solution




Given definition void methodName(int x, char y) in method call
methodName(a, b) a must be an int and b must be a char
Store variables and their types in one vector and method names
and their parameter types in another
When method call is found in code, make sure its parameter types
match those in vector
If they don’t match, return an error
Problems



Multiple entries - will return false error
Mismatched parameter types - will not detect error that is there
Types don’t have to match exactly - a double can take an int
Invoking a Non-void Method as a Statement

When a non-void method is called it returns a value of some
type and it must be stored somewhere.
For example: public int someMethod(){
int result; ...
return result;}
is then being called as
someMethod()
instead of
int someResultVariable = someMethod()

Solution



Store all method names
Every time when there is a method call check to see if it is
preceded by an operator like = or + or by (
If there is no variable that stores the return value an error message
is returned
Class Declared Abstract

Every Java interface being implemented in an applet requires that
certain methods or adapters need to be present in the code even if
they are empty

For example: someClass extends Applet implements ActionListener{
public void init(){
...}}
instead of
someClass extends Applet implements ActionListener{
public void init(){
...}
public void actionPerformed(ActionEvent e){
...}}

Solution



Create a list that associates every interface with the appropriate methods or
adapter
If an interface is implemented, a search for the required components is
performed
If some methods or adapters are missing, an error message is returned
Sample Run Code
// sample run
import java.awt.*;
import java.applet.*;
import java.awt.event.*;
public int computeSum(int apple, int sauce){
int appleSauce;
if (apple = sauce){
appleSauce= apple + sauce;
}
else if (apple > sauce);{
appleSauce == apple - sauce;
}
else{
appleSauce = 49;
}
return appleSauce;
}
public class SampleRun extends Applet implements ActionListener {
Label sampleLabel = new Label("Sample Label", Label.LEFT);
Panel samplePanel = new Panel();
public void init();{
samplePanel.setLayout(new FlowLayout(FlowLayout.LEFT));
samplePanel.add(sampleLabel);
add(samplePanel);
repaint();
}
public void paint(Graphics g){
char bear = 'p';
String cheese = "appleSauce";
computeSum(cheese, bear);
}
}
Sample Run Outcome
Conclusion



Our aim in this project was to create an educational tool
that would not only help students identify and fix their
existing programming errors, but also help prevent them
from making them again in the future.
We accomplished this by compiling a list of common Java
programming errors made by introductory students,
designing and coding a program that identifies these
mistakes and returns instructive error messages, and
testing our program on our test suite.
We believe that our resulting project will prove to be a
very useful tool for future introductory Computer Science
students.
The Future of Our Project



Assessment of the tool’s effectiveness in the
classroom environment and examination of these
results and student feedback to be reflected in future
implementations
Submission to Computer Science Education Journals
for Publication
Submission to SIGCSE Conference for Student Paper
Presentation
Acknowledgements
We would like to thank:
* our families and friends for their support throughout this project
* each other for the super team work, patience and understanding that
made this project possible
* Professor Rebecca Mercuri for her mentoring
* the Computer Science department at Bryn Mawr College and especially
Professor Deepak Kumar without whose enthusiasm and love for
teaching none of us would be Computer Science majors
* Anneliese Taylor who is the best science librarian that we know
* Bryn Mawr College for establishing an environment where women can
excel in science
* and Collaborative Research Experience for Women, part of the Computer
Research Association for their financial support with this project and
their dedication to encouraging women in Computer Science.
Bibliography
Du Boulay, Benedict. “Some Difficulties of Learning to Program.” Journal of Educational
Computing Research Vol. 2(1). (1986): 57-73.
Fleury, Ann. “Programming in Java: Student-Constructed Rules.” Proceedings of the Thirty-First
SIGCSE Technical Symposium on Computer Science Education (2000): 197-201.
Kurland, D. Midian and Roy D. Pea. “One the Cognitive Effects of Learning Computer
Programming.” New Ideas in Psychology Vol.2 No.2. (1984): 137 – 168.
Pea, Roy D. “Language-Independent Conceptual “Bugs” in Novice Programming.” Journal of
Educational Computing Research Vol. 2(1). (1986): 25-36.
Kolling, Michael. The BlueJ Tutorial Version 1.4. 23 January 2002 <http://www.
bluej.org/tutorial/tutorial.pdf>
Kolling, Michael. Why BlueJ? 22 January 2002 <http://www.bluej.org/why/why. html>
PLT Scheme: Software: DrScheme Home Page. 22 January 2002 <http://www.pltscheme.org/software/drscheme/>
TA Online: Common Java Compiler Errors. Department of Computer Science, University of
Arizona. 17 February 2002 <http:// www.cs.arizona.edu/people/teena/ ta_online/>