INSTRUCTIONS FOR THE PROGRAMMING IN C PROJECT (Fall 2011)

GENERAL

The project work is part of the course programming in C. Only those who have returned the project can participate in  separate exams. You can particape in the course exam even if you have not yet returned your project. The project work IS COMPULSORY. If it has not been completed, you may not enter  separate exams.

The project should be returned by Tuesday,  NOVEMBER 1.  If you have good reasons, it is possible to get one week more time.

A GROUP WORK OR AN INDIVIDUAL WORK

The project is recommended to be done in a group (2-3 persons). Group works should have in addition a test module to the data structure module. In groups each member should do about the same amount of work. In group works there should be written as a comment to each function who has done it.

You are responsible for the timetable yourself.

REQUIREMENTS (DEMANDS)

  These features should be found in the code:

• Linked data structure with pointers (stack, list, tree, ...) if project permits.
• Reaging and writing from a file (text or binary file)
• Command line parameters (if you do not found anyting else, include at least -h for help)
• Functions with parameters

Use also other features, if the solution demands for it. You may work on whichever computer you wish, but the resulting program must run on any Linux machine in the CS Department (so keep portability in mind). Your program should be compiled by gcc with options -ansi -pedantic -Wall and Wextra without warnings. You may also use c99 standard. There should be at least two separately compiled units. There should also be a makefile. And make command should make a runnable program.

Outline the problem field and set the function specification, data structures to be used and the main strategies of the solution. Present your choices and solutions to the instructor. A good set of data structures may save you a lot of code writing.

Evaluate the feasibility of your plan:

• The first solution that comes into your mind is not necessarily the best one.
• You should not invest too much time and energy into a bad solution at an early stage.
• A good program functions as it is supposed to, efficiency is often less important.

Put the presentations of functions, type specifications of data structures etc. into specification files with the ending

.h

. The actual code and variable specifications should be put into source code files with the ending

.c.

Always make a separate main program and put functions that belong together according to some obvious task that they do together in their own source code files.

Always use good taste:

• coherent programming style
• avoid peculiar and cryptic language in your coding
• a shock-proof program neither creaks nor crashes
• add brief instructions
• variables: descriptive names that take into account their purpose, meaning and use

Testing should be done systematically from the beginning. You can find small errors and 'suspicious' parts with the option -ansi -pedantic -Wall -Wextra in the gcc compiler.

DOCUMENTATION: A NECESSITY

Make a short help file (2-4 pages) including structure document of the program and instructions how to use the program. Make comments in code files and give a brief explanation about testing in your documentation.

Document your program:

• Each program file contains a general comment:
  • What the file is intended to
  • What functions the file contains
  • Which of the other files' functions the file uses
  • Library functions do not have to be listed
• Clarify the main data structures
• For each function, explain:
  • What the function does
  • What its parameters are
  • What it returns
  • What it changes
• Avoid unnecessary commentation. Use clear variable names, the structure of the language is assumed to be known, etc.
• Comment on difficult and exceptional solutions

HANDING IN THE PROJECT: HOW TO DO IT

Make one tar-package that is easy to open. The package should contain all material of the project work:

• all the code and specification files for the source language
• the file Makefile with which the program can be compiled
• files used for testing and other material from testing
• a readme file specifying how to handle your program.

You can return tar-file also as a compressed tgz or gz file to Timo Karvi ( Timo.Karvi@cs.helsinki.fi). 

(Instructions for tar-making and file compression)

PROJECT MARKS

Project work carries ten marks:

• programs wideness and difficulty, (1-2 p)
  • 1 p implemets the programming task moderately
  • 2 p implements the programming task extremely well
• main strategies of the solution. (1- 2 p)
  • clear, logical and working solution for data structures
  • how well the program is divided in modules
• the structure of the program (how well the program is divided into functions), logical and effective use of C-language (1-3 p)
  • how well the program is divided into functions (0-1 p)
  • use of the C-language (0-2) and good programming style
• programs exterior features and readability (comments, variable names, indentation, coherent programming style) (0-1 p)
• testing and test cases (0-1 p)
• document (1 p)

Marks are suggestive. Marks can vary accorging to the programming task.

Program is returned to be corrected, if

1. compilation of the program is not succesfull
2. program stops in a severe runtime error
3. program is not at all doing what is should do
4. documentation is missing totally
5. test description of the program is missing totally
6. there are no functions in the program
7. marks are less than 3
8. Some of the features are missing (linked data structure with pointers, reading and writing from a file, command line parameters)
9. the program is not divided into separate compilation units
10. Makefile is missing

Good luck for your work!