Introductory Programming Classes Research Articles

OZ

In response to the needs of students taking introductory programming classes, we have a created a syntax generating editor. This simple to use and reasonably powerful editor helps students avoid syntax errors and also greatly eases and speeds the typing of programs. This is especially true in Modula-2 where the frequent need to change between upper and lower case places exhausting demands on even good typists. Changes in a configuration file allow the editor to work with a number of different programming languages. The editor is written in Pascal and runs under VAX/VMS. Source code, executable code, and documentation are available over the Internet.

An introduction to object-oriented programming through Turbo Pascal

This paper presents three introductory concepts of object-oriented programming: encapsulation, inheritance and polymorphism. The specific implementation for these concepts and other terms presented, is the language Turbo Pascal (5.5 or later). The examples illustrated have been successfully used as the first part of an introductory object-oriented programming class.

Development and documentation of computer programs in undergraduate computer science programs

Until recently, introductory programming classes in the Department of Computer Science, University of Minnesota, Duluth, concentrated on writing code. Not until the junior or senior year were students required to adhere to basic principles of software engineering. As might be expected, by their junior year students' bad habits, like coding while designing or inserting comments last, were firmly entrenched and difficult, if not impossible, to undo. The solution, it seemed to us, was to prevent bad habits right from the start. Consequently, we developed guidelines for designing and documenting the entire programming effort, from problem statement to post mortem. The guidelines include such steps as: algorithm development in high-level pseudocode with stepwise refinements, structure diagrams with data flow, detailed test descriptions, testing results, and a description of all known bugs. For a given assignment, the instructor chooses the steps to be completed, allowing for flexibility and appropriateness in the design and documentation. Results have been extremely positive. Students start earlier and produce better organized solutions. More students solve the problems correctly. Most importantly, students develop design and documentation skills in the freshman year that carry through and are improved over their four-year stay. Because of this initial success, our department has adopted these guidelines uniformly in all programming classes. In this paper we will describe our guidelines and give some details of their use. We will discuss the philosophy that led us to develop these guidelines and present our observations of their effectiveness.

The challenges of teaching computer programming

The challenges of teaching computer programming

A survey of run-time and logic errors in a classroom environment

This paper presents the results of a survey of programming errors in an introductory programming class conducted at Kansas State University. The objective of the study was to gain a better understanding of some of the errors made by beginning student programmers, particularly those effors normally detected by run-time packages (e.g., undefined variables, division by zero, arithmethic overflow) as well as the many effors that pass undetected by compilers and run-time tools (e.g., logic and conceptual effors). The survey involved the analysis of 1088 program runs collected from approximately 50 students in a FORTRAN programming course.The effors were tallied and analyzed, and were then recorded under eight general categories: Input/Output (e. g., missing I/O statements, missing or incorrect I/O variables or data); Assignment (e. g., incorrect operators, missing assignments); Loops (e. g., incorrect loop parameters, missing or extra loops); Decision and Branching (e. g., jump to wrong places, incorrect decisions; Arrays (e. g., incorrect subscripts, missing array); Subprograms (e. g., incorrect or missing parameters, incorrect number of calls); Declarations (e. g., issing or wrong declaration statements, wrong names in declaration statements); and Miscellaneous (e. g., unused variables, redundant decisions, wrong logic). The study found that two classes of errors accounted for over half of all noncompiletime errors: those errors related to input/output and assignment statements. Further analysis showed that less than half of the run-time error messages generated by the compiler actually pinpointed the cause of error or provided a meaningful hint.

A predictor for success in an introductory programming class based upon abstract reasoning development

The purpose of this study was to create and validate a tool which could be administered to students enrolled in or considering enrollment in an introductory programming course to predict success in the course or alternatively to segregate enrolled students into fast and slow paced sections. Previous work which met the criteria of a self contained predictive tool included the work of Barry Kurtz [5] of the University of California, Irvine using abstract reasoning development as the predictive measure. The test Kurtz developed had been tested only on a small sample (23 students) in a controlled environment (one instructor - the researcher) and the test required up to 80 minutes to complete. This study modified the Kurtz test to require 40 minutes and administered it to 353 students learning two different languages from a variety of instructors. This predictor successfully predicted the advanced students from average to below average students. When used in conjunction with other known factors, e. g., GPA, the authors feel it is a viable tool for advising and placement purposes.

Investigating the relationship between the development of abstract reasoning and performance in an introductory programming class

A test of formal (or abstract) reasoning abilities was given to students in an introductory programming course. Based on these results, students were classified at three intellectual development (ID) levels: late concrete, early formal, and late formal. Performance in various aspects of the course was analyzed by these three ID levels. It was found that: (1) ID level did not vary with sex, class level, and previous coursework; (2) the levels of late concrete and late formal are strong predictors of poor and outstanding performance, respectively; and (3) the ID level predicts performance on tests better than performance on programs.

A comparison of PASCAL and FORTRAN as introductory programming languages

Many colleges and universities offer introductory programming classes based on the FORTRAN language. Several of these schools are contemplating a change to a more modern programming language in this first course. The Department of Computer Science at the University of Colorado has recently made the transition from FORTRAN to PASCAL, and this paper offers an informal discussion of the experiences of one instructor during that change. It is hoped that others who may be considering a similar change will benefit from our experiences.

An experimental investigation of the effect of program structure on program understanding

A within-subjects experimental design was used to test the effect of two variables on program understanding. The independent variables were complexity of control flow and paragraphing of the source code. Understanding was measured by having the subjects memorize the code for a fixed time and reconstruct the code verbatim. Also some subjects were asked to describe the function of the program after completing their reconstruction. The two groups of subjects for the experiment were students from an introductory programming class and from a graduate class in programming languages. The major findings were that paragraphing of the source had no effect for either group of subjects but that programs with simplified control flow were easier for the computer science students to understand as measured by their ability to reconstruct the programs. The dependent variable, rated accuracy of their description of the programs functions, did not differ as a function of either independent variable. The paper is concluded with a description of the utility of this experimental approach relative to improving the reliability of software and a discussion of the importance of these findings.

An experimental investigation of the effect of program structure on program understanding

A within-subjects experimental design was used to test the effect of two variables on program understanding. The independent variables were complexity of control flow and paragraphing of the source code. Understanding was measured by having the subjects memorize the code for a fixed time and reconstruct the code verbatim. Also some subjects were asked to describe the function of the program after completing their reconstruction. The two groups of subjects for the experiment were students from an introductory programming class and from a graduate class in programming languages. The major findings were that paragraphing of the source had no effect for either group of subjects but that programs with simplified control flow were easier for the computer science students to understand as measured by their ability to reconstruct the programs. The dependent variable, rated accuracy of their description of the programs functions, did not differ as a function of either independent variable. The paper is concluded with a description of the utility of this experimental approach relative to improving the reliability of software and a discussion of the importance of these findings.

An experimental investigation of the effect of program structure on program understanding

A within-subjects experimental design was used to test the effect of two variables on program understanding. The independent variables were complexity of control flow and paragraphing of the source code. Understanding was measured by having the subjects memorize the code for a fixed time and reconstruct the code verbatim. Also some subjects were asked to describe the function of the program after completing their reconstruction. The two groups of subjects for the experiment were students from an introductory programming class and from a graduate class in programming languages. The major findings were that paragraphing of the source had no effect for either group of subjects but that programs with simplified control flow were easier for the computer science students to understand as measured by their ability to reconstruct the programs. The dependent variable, rated accuracy of their description of the programs functions, did not differ as a function of either independent variable. The paper is concluded with a description of the utility of this experimental approach relative to improving the reliability of software and a discussion of the importance of these findings.

Whither flowcharting?

During the past few years, a growing number of authors have begun to take exception to the previously unquestioned use of flowcharts as a program development tool. These criticisms of the traditional flowcharting methodology center around the claim that flowcharts, like goto's , belong to the class of objects that are detrimental to good programming. Suggested alternatives range from developing programs entirely in well-structured high level languages to replacing conventional flowcharts by some form of “structured” flowcharts. We are particularly concerned with questions that have been raised regarding the value of flowcharting in introductory programming classes. The teaching of flowcharting as a developmental tool is extremely widespread indeed. While the various methods of indicating data flow, document flow, etc., are certainly an important part of program development and documentation, we consider here only conventional “flow of control” flowcharts.