CMSC--202 , Section 1 Computer Science II for Majors
Fall 1997 28 July 1997 Guidelines for Programs

Academic Honesty

All programming assignments must be your own work. You may discuss assignments with anyone, but you may not copy work. Every detail of your assignment must be your work. You may use any material you obtain from the instructor, TA, grader, or Help Center.

Here are some examples of OK and NOT OK interactions with fellow students:

OK

Discussion of a feature of the C language and how it may apply to the assignment.

OK

Discussion of the requirements of the assignment.

OK

Discussion about a general approach to the assignment.

OK

Discussion of a detail or two about the assignment. No one makes notes, just talk.

NOT OK

Writing down a small section of a fellow student's assignment for later inclusion in your assignment.

NOT OK

Looking at a fellow student's assignment, even though no notes are written down.

NOT OK

Having another student's work in your possession at any time, even briefly.

These examples are provided to help clarify your responsibilities. They are not all-inclusive. Please note that they are aimed at encouraging general discussion but are very strict about doing your own work.

Style Guidelines

It is important to follow these style guidelines for all programming assignments. You may lose substantial credit if you do not follow these guidelines.

• No global variables. You may use global constants, but do not use global variables under any circumstances.

• No file-scope static variables. You may use local-scope static variables within a function.

• Every file must be headed with comments showing the file name, a brief description of the file contents, your name, the creation date, and the date of last modification. Here's an example:

    /*
      hw1.c
      CMSC-202, Fall 1997, Homework 1, main function
      Thomas A. Anastasio
      Created: 24 July 1997
      Current: 26 July 1997
    */
  
         ....  remainder of file  ....
  

• Every function must be commented to show the purpose of the function, what it returns, and an explanation of each of its parameters. Here's an example:

     /* 
        CommentDemoFunc
        Demonstrates a correct commenting style. Prints legend.
        Returns 1.
     */
     int CommentDemoFunc (char * legend)
     {
        printf("%s\n", legend);
        return 1;
     }
  

• Variable names and function names should be chosen to be self-explanatory. Comments should be used to explain major sections of code and to explain code features which are not obvious. Whenever possible, code should be written such that it is ``self-commenting.''

• The main function should be quite simple. Avoid having a lot of code in the main function. Ideally, it should consist of calls to other functions, perhaps embedded in a single loop. Do not have excessive computation in your main function. The main function should be in its own file.

• Each file should #include only those files which are needed for compilation. Extraneous include files should be avoided.

• Each file must have comments at the top giving the name of the file and your name.

• Every header file you write must be guarded. Here is an example of a guarded file. The guard consists of the compiler directives #ifdef, #define, and #endif.

    /* 
       hw1_aux.h
       Interface file for HW-1, CMSC-202, Fall 1997
       Thomas A. Anastasio
       Created: 24 July 1997
       Current: 26 July 1997
    */
    
    #ifndef HW1_AUX_H
    #define HW1_AUX_H
    
           ....   here you put the usual interface file code .....
    #endif