CVE Project Source Code Format Requirements

All CVE project source code should follow a set of consistent formatting conventions, which we inherit from the Icon Project at the University of Arizona; these same conventions are also used in Unicon Project source code. This page summarizes some highlights from IPD 72 as interpreted for this group.

The goal is for the whole source code to be easily readable and printable, and for it to read as a single consistent unit, as if it were written by one person instead of 12 people.

This applies to both Unicon and C source code written for the project.

Lines are to be at most 79 characters long, for convenient viewing and printing on all terminals and printers. Yes, I want to be able to trivially print an entire hard copy of the project source code and stick it in a 3-ring binder for review. You can insert page breaks (control-L) in the source code, on lines by themselves, that are ignored by the compiler and editors but improve the hard copy printing of long files.

Formatting is 3 spaces per level of syntactic nesting. Initial tabs may be used, equivalent to 8 spaces per tab. So three levels deep of intentation can be done as 9 spaces or as 1 tab followed by 1 space. Curly braces are to be lined up generally as follows:

   if foo then {
      # stuff in the then-body
      }
   else {
      # stuff in the else body
      while bar do {
         }
      }
The opening curly is on the line that owns or initiates the block of code. The closing curly is at the same level as the code it closes. This may be unfamiliar to some of you but it is not that hard to do.

There are emacs modes for Unicon and Icon out there that can help with the indentation. Otherwise, you are on your own.

Comments are of the form:

   #
   # This is a sample comment
   #
   this is the code to which the comment applies.
It is indented at whatever level the code it refers to. Shorter comments directly on the ends of lines they discuss are generally discouraged, with the exception of variable declarations.

Do not use long ################ repetitions of characters to mark header comments, other than at the very beginning of a file, where you are allowed to do this using the format Ralph Griswold uses for the Icon Program Library files.

Your personal names are not generally to be repeated in every spot in every file where you happen to make a change. Rest assured, I and your teammates can use CVS to see who has written what code, and how much you've done.