Software 1
Summer 2003

Submission Guidelines

General

These notes will guide you through the process of submitting your homework in the course Software 1 offered in semester Summer 2003. The content of the various assignments will be separately detailed. The solutions will be checked both by a human and by a machine (an automatic program). Therefore, it is crucial to follow precisely the guidelines below. Failing to comply may lead to the failure of the automatic checking mechanism, which in turn, will cause a degradation of your assignment grade.

Procedural Issues

• You must submit all the assignments by yourself. You may share ideas, but you may not share code.
• You must submit on time. If you serve in the army during the semester, and need an extension, you must present an official confirmation. Failing to submit the homework in time due to any other reason is unacceptable, and will be regarded as if not submitted at all.
• The code for the solutions must comfort to the ANSI C specification. The programs should be compilable and executable on the UNIX machines in the Computer Science school, using the default gcc compiler. Developing on other systems and porting the files to UNIX will not be an accepted excuse for delays or any faults in the programs.
• Your solutions must be submitted electronically only in the form of files in your UNIX account (see details below).
• Code lines should not exceed 80 characters, and the code should be nicely indented.
• Each source file should have a header section that contains the following information:
  • Your full name.
  • Your ID number.
  • Your user name (login).
  • The number of the group you are registered to {10, 11, 13, or 14}.
  • Assignment number.
  Please add the information using the following format:

  /* .....
   * Full Name: you-full-name
   * Id No: your-id
   * User Name: your-user-name
   * Group No: your-group-number
   * Assignment No: the-assignment-number
   * .....
   */
  

Files and Directories

• The programs should be compiled, linked, and executed under nova or any other Linux system on the network. They should be compatible with the gcc default compiler. Your code should generate no warnings whatsoever when compiled with the -Wall command line option. The use of the -pedantic command line option is recommended. You may also use the -g option for debugging purposes.

  gcc -Wall prog.c -o prog

• The files should be submitted on the UNIX file system. You should have a subdirectory under your home directory, called software1. For each assignment, you should create a subdirectory under which you will create and leave the source files, with appropriate names as required. The names of the subdirectories will be assigni, where i is the number of the assignment. For example, the programs for assignment 1, should reside in ~/software1/assign1/.
• These directories should contain exactly the files required in the assignment. Each exercise is given a name. This name is assumed to be the name of the executable and the basename of a source file, in most cases the sole source file for the exercise.
• You must not touch or change the files you submit after the deadline due date. Each file has a property of the last time it was modified. Files that are modified after the deadline will be considered as not submitted on time.
• The permissions of the entire path from your home directory down to the exercise files themselves should be 705. You may use the following commands (where assign1 will be changed to assign2 in the second assignment, and so on):
  

  chmod 705 ~ chmod 705 ~/software1 chmod 705 ~/software1/assign1 chmod 705 ~/software1/assign1/*

Input / Output

Unless explicitly stated otherwise, your programs should read their input from the standard input, and write their output to the standard output. Sometimes you will be given sample input and output files. Those will be accessible through the assignment page, and typically be named after the name of the exercise. For example, the input and output files for exercise prog from assignment 1 might be called prog1.in, prog1.out, and so on. In order to test your program prog against that input you should download these files to your directory. Then, you should execute the command:

prog < prog1.in > myProg1.out

Then, you may compare your results with the expected results using the command:

diff prog1.out myProg1.out

Your programs should generate the exact same output as the example. Specifically, do not add friendly messages (e.g. "please enter a number:") to your code. The automatic checking programs do not tolerate this, and the slightest difference will lead to loss of points.
Each error message produced by your program must be constrained to one line, and must start with the word ERROR. For example:

ERROR: out of memory ERROR: invalid input data

Note: You should check your application with relevant input files, covering as many cases as you can think of. You may use the given sample files if available to test your program, but keep in mind that other input files will be used in the actual check. You should think of as many boundary cases as possible (in case of real numbers it may be fractions, zero, or negative values. in case of text it might be spaces, empty lines, etc.)

Support

Unclear issues, or problems regarding the UNIX environment, the nova machine, or any other system related issues should be directed to the system consultants. They can be accessed via email system@cs.tau.ac.il, or in person in the advisor's room on the first floor in Schreiber building, room 019.

Other questions, regarding procedural or programming issues should be coped in the following order:

1. Read the relevant exercise instructions and the general submission guidelines (this page) carefully.
2. Go over the FAQ page.
3. Take a moment and think again whether the question makes sense and cannot be solved alone.
4. Questions regarding the checking procedures, grades, directories and files that were misplaced, etc. please send to tochna1@post.tau.ac.il (your exercise checker).
5. If all else fails (or for other course-prcatice related issues), send an email to efif@post.tau.ac.il stating the question shortly and clearly with Software 1 as the subject field.

Grading Criteria

1. Submission on time - making any changes to the files after the due date will be regarded as not submitting at all. As a rule of thumb, there will always be an 'objective' problem in the day preceding the submission; a power failure, a printer malfunction, printer running out of paper, etc. Therefore, prepare your homework way in advance. Leave plenty of time for debugging, testing, and dealing with unexpected problems. Unexpected problems are the most expected things in programming projects!
2. Correctness of the program - The correctness will be checked by an automatic mechanism, and therefore special care should be taken meeting the exact syntactic requirements.
3. Implementation efficiency - Your programs are expected to be reasonably efficient.
4. Documentation - The inline documentation is composed mainly of a reasonable amount of comments (when needed). Make sure that each file and function include a short paragraph explaining its purpose, IO and method of work.
5. Readability - Use intelligent naming for variables and functions.
6. Indentation - Indent the code properly.
7. Code correctness - The code correctness will be measured according to various software engineering criteria, such as clarity, intelligent naming, division into functions, use of comments, etc.