Coding Guidelines for Prolog

Introduction

The purpose of programming languages is to make programs readable by people. Coding standards enhance this function, especially when multiple programmers and a need for maintainability are present, but also even in the small projects of a single programmer (one must, after all, read and debug one’s own work). Coding standards for Prolog are particularly needed for several reasons:

Availability. As far as we know, a coherent and reasonably complete set of coding guidelines for Prolog has never been published. Moreover, when we look at the corpus of published Prolog programs, we do not see a de facto standard emerging. The most important reason behind this apparent omission is that the small Prolog community, due to the lack of a comprehensive language standard, is further fragmented into sub-communities centered around individual Prolog systems, none of which has a dominant position (contrast this with the situation of Java and Sun’s coding conventions for that language (Sun Microsystems, Inc. 1999) or the precedents set for C by the UNIX source code).

Language. Language features that contribute to the power of the language make it quite easy —especially for the non-expert— to get things wrong, sometimes in ways that are difficult to diagnose. For example, the lack of prescriptive typing contributes to the suitability of Prolog for quick prototyping in some application domains. At the same time, the fact that no redundant type information is available to the development tools makes discipline particularly important. Besides types, Prolog developers and maintainers are confronted with modes: the same arguments of procedures can be inputs, outputs, or both. This gives Prolog conciseness and elegance through reversible predicates but makes it necessary to keep track of which modes are supposed to be supported (within reasonable computational complexity limits) by which predicates.

Compiler technology. Most Prolog compilers give no warnings except about singleton variables. Even though more advanced tools and development environments exist, a disciplined approach is still (and will always be) the best device available to those programming in standard Prolog (and any other language).

It is important to stress that we are not announcing the coding standard for Prolog. This is a paper with five authors and, on some points, more than five opinions. Rather, we address numerous issues that the maker of a full-fledged coding standard will have to confront. In some cases, there are good reasons to prefer one alternative to another. Other decisions are arbitrary, like driving on the left or on the right; a community of programmers can choose any of several ways of doing something as long as they are consistent. The classic style guide is The Elements of Programming Style (Kernighan and Plauger 1978). Published in 1978 and using examples in PL/I and Fortran, the majority of its advice is independent of programming language and still much needed. Indeed, some of our own guidelines are not Prolog-specific but are included because no style guide for practitioners would be complete without them.

The amount of standardization needed depends on the scale and duration of the programming project. Just like a novel or a scientific paper, the quality of a computer program can only be judged from the degree to which it satisfies the programmer’s objectives, i.e., “it works”: for example, we might say that a novel works if it becomes a best-seller, the manual of a device works if it enables the average user to effectively operate the device, a scientific paper works if it is published in a prestigious journal. Computer programs written for different purposes may or may not “work” in different ways. Only for very simple programs written to solve very simple tasks, we can say that the program works if it functions correctly. For even moderately complex programs a more sensible definition could be: the program works if its developers and maintainers are able to approach the expected behavior of the program over its intended lifespan.

In some cases, correctness and maintainability over a long period of time are not important. For instance, in the rapid prototyping of applications (something for which Prolog has its advantages), we might say that the program (prototype) works if (despite its errors and limitations) it demonstrates that the approach is feasible. Still, the prototype will be incomplete until it is finished, and its chances of being finished one day (as opposed to collapsing and being abandoned before being of any use) depend on qualities such as readability, extensibility, and whatever else helps the development team.

In a sense, the text of a program is not very different from an argumentative essay. Like an argumentative essay, a nontrivial program is addressed to an audience, which needs to be accurately identified for the argumentation part of the program to be effective. As for any argumentation, different audiences will require and be prepared to share a different set of premises (hypotheses and preconditions explicitly mentioned in the program text) and assumptions (hypotheses and knowledge that are left implicit but that still are essential for the comprehension of the program). Not to mention that, in programming, the intended audience is also heavily influenced by the tools it is used to.

To summarize, the existence of very different purposes and wildly different audiences are such that a full-fledged coding standard can only be decided upon on a per-project basis. Moreover, different, equally reasonable and effective coding standards can, on specific points, recommend plainly opposite things: a coherent whole matters more than the individual bits.

In this paper, which evolved from (Covington 2002), we introduce a set of coding guidelines that can serve as a starting point for the development of effective coding standards. We highlight the aspects of Prolog program development that deserve particular attention and can benefit from regulation; we illustrate the rationale that is behind each of the proposed guidelines; when alternative guidelines can achieve the desired effect, their relative merits are discussed.

The paper is organized as follows: in Sections 2, 3 and 4 we discuss guidelines concerning code layout, the naming of program entities, and documentation, respectively; Section 5 concerns the effective use of language features; Section 6 deals with the development, debugging and testing of program units and their interfaces; Section 7 concludes.