We also wanted students to learn to use a correct programming style as a matter of habit. We assumed that with CAP continually telling the students to fix their programming style, eventually they would learn to do it correctly from the beginning. Unfortunately, we believe that many students began using CAP as a crutch to merely get by. Rather than incorporating the required programming style rules into their programming habits, some students ignore style altogether knowing that CAP will annotate their code with all the corrections that are necessary. These students have become dependent on CAP and could not program to our standards without it. This is the opposite effect that we wanted. Fortunately, we believe this number to be small, although further testing is warranted to determine if the problem is wide-spread. Additionally, it is likely the result would be the same for these students in the absence of CAP.
The diverse nature of undergraduate curricula in computer science demands a wide range of programming language support. Students are exposed to a variety of programming languages such as Pascal for introductory programming, Modula-2 for concurrent programming, C for systems programming, and Smalltalk or C__ for object-oriented programming. The proliferation of programming language environments, and CASE tools in undergraduate curricula impose an overload of syntax on both educators and students. Our limited teaching time is wasted introducing new syntax and not new concepts.
A solution to these problems requires an environment that provides a wide range of language support under a common syntax, combined with an integrated collection of coding and CASE tools. Such an environment could be used as a “curriculum-cycle” tool for teaching programming at all levels of an undergraduate curriculum in computer science.
Students in the introductory courses appreciate both the language and the easy to use environment much in the same way Turbo [Borland] users do. Shielded from the complexity of having to use several losely-coupled tools, beginners are able to concentrate on the important task of learning the concepts behind programming.
In 1991, the Stanford Department of Computer Science decided to abandon Pascal in its introductory computer science courses and to adopt ANSI C as the language of instruction. We based this decision on several factors: the inadequacy of standard Pascal as a base for teaching modern programming concepts, the need to prepare our students for more advanced courses in which they will be expected to use C for programming projects, and increasing pressure from students and faculty throughout the School of Engineering for instruction in a language that has become the industry standard. We also believe that it is not reasonable to expect students to learn C on their own; students must receive instruction in C in order to become good C programmers. C has several known deficiencies that make it a challenging language to teach.
Over the last five years, however, many schools have begun to move away from Pascal. The reasons behind this shift include:
- Pascal is getting old. There are several modern programming concepts, such as separate compilation, string manipulation, and the use of functions as first-class objects, that are not supported by standard Pascal and that are therefore difficult to teach.
- The restrictiveness of Pascal’s design occasionally forces its users to “program around the language.” Doing so means that students develop certain bad habits—habits that they must later unlearn when they begin to work with more modern languages.
- Pascal is not widely used beyond the introductory sequence, and students are therefore being taught programming style and the discipline of software engineering in the context of a language that they will never again use. The first course must provide an introduction to good programming practice. Unfortunately, the effectiveness of that instruction is compromised when the linguistic tools used to illustrate the underlying concepts are so quickly abandoned.
Pan is intended to support experienced professionals who manage large collections of interrelated documents. Many common assumptions about language-based editors, traditionally oriented towards novice authors, do not hold in this domain.
Understanding is the primary activity.
There are many languages.
Languages and usage change.
Users are fluent.
It is expected that about eighty percent of COBOL syntactical errors can be accurately diagnosed by this expert system and that about fifty percent of the runs of students will be for the purpose of correcting syntactical errors. Assuming that run time errors are about half as frequent as syntactical errors, then an additional twenty to thirty percent of the error frequency should be contained in run time errors.
Turing is a general purpose language designed for convenient development of reliable, efficient programs. Its language design goals include ease of learning, concise and expressive syntax, graceful and efficient treatment of errors, control of program complexity, mathematically precise language definition, and small, fast implementation.
Nothing in the paper about syntax error handling.
Results
The mean percentage of correct answers for the SEE-produced format was 44%, whereas the percentage for the conventional format was 35%. A within subjects analysis of variance showed that the effect of presentation format was significant, F(1,42)=18.25, p<0.0001. In short, we found that the enhanced source text presentation increased the programs’ readability by 25% as measured by the subjects’ performance on a comprehension test, and this result was significant at the p<0.0001 level.
http://portal.acm.org/citation.cfm?id=55858&coll=portal&dl=ACM&CFID=44293511&CFTOKEN=74689263#
We believe that programming style is a multi-faceted concept that is not captured by a collection of rules or by a single style score. Instead we propose that programming style is best analyzed by separating stylistic factors into classes and then studying the affects of these factors on program comprehension and maintainability. We have found it useful to break programming style into two classes: those pertaining to typographic arrangement and those measuring the structural content of the code.
Factors belonging in the typographic category include level and method of indentation, line length, detail and placement of comments, placement of blank lines, use of embedded spaces, identifier length, module length, and formats for type and data declarations. The structural style category includes factors for modularity, use of labels and gotos, use of constant definitions, use of included files, use of literals, methods of type and data declarations, use of library functions, level of nesting, control flow, information flow, operator and operand usage, and other factors related to program complexity.
Conspicuously absent from this paradigm are the more nebulous characteristics of style–the evaluation of economy, simplicity, readability, and other such traits. We recognize the importance and impact of these characteristics and suggest that controlled studies need to be directed at each of these factors in turn. We do not claim that our operational classification and corresponding list of factors completely captures programming style. Rather, our paradigm represents a modest start at formalizing an approach and methodology used for research on programming style.
http://portal.acm.org/citation.cfm?id=57675&coll=portal&dl=ACM&CFID=44293511&CFTOKEN=74689263
The bugs in programs were grouped into 6 categories. Using total bugs identified, the group using DEBUG was able to find more of the bugs than the control group, although the difference was not significant at the 0.05 level. When each of the categories were analyzed separately, the DEBUG group did perform significantly better (0.05 level) at identifiying illegal references and potential zero divides. Since this is something which the utility identifies directly, the finding seems reasonable. Many of the anomalies which DEBUG detects require subsequent interpretation. At this time, the information supplied by the utility on potential problems which can arise given the detection of some anomaly, is very sparse. Future enhancements will extend the facility for providing information on potential error sources and remedies.
Generally, students who used the facility found it easy to use and effective in helping to locate logic problems, even with its limited capability. Increased training time was mentioned as a feature which would enhance the utility. Sufficient evidence existed, along with many positive comments regarding features which would enhance the utility of DEBUG that extensions have been made. Some of these are already incorporated as part of this paper (e.g. additional data types).
Although many guidelines and articles have been written about improving error messages, only a handful of empirical results have been reported in the literature. In separate experiments involving COBOL compiler messages, text editor messages, and job-control language messages, Shneiderman reports experimental results that support the conjecture that the wording and content of messages can impact user performance and attitude.
Testing of error messages is clearly something that must be done if designers are to be sure that users will be able to successfully correct their mistakes. For any given user error situation, program developers must assure that a typical user can make the appropriate correction. However, testing messages in the context of product use or while performing other more general product usability tests poses two problems: first, not all messages will get exercised; and second, when multiple errors occur, it is difficult, if not impossible, to know which error a user is trying to correct.
http://portal.acm.org/citation.cfm?id=801583&coll=portal&dl=ACM&CFID=44293511&CFTOKEN=74689263#