|
General
These notes will guide you through the process of submitting your homework in
the course Software 1 offered in semester
Spring 2004. 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
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.
- 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:
- Read the relevant exercise instructions and the general submission
guidelines (this page) carefully.
- Go over the FAQ
page.
- Take a moment and think again whether the question makes sense and cannot
be solved alone.
- Questions regarding the checking procedures, grades, directories and
files that were misplaced, etc. please send to
tochna1@post.tau.ac.il
(your exercise checker).
- If all else fails (or for other course-prcatice related issues), send an
email to
efif@post.tau.ac.il or
gretay@post.tau.ac.il stating
the question shortly and clearly with Software 1
as the subject field.
Grading Criteria
The grades will be composed of the following parts:
- 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!
- 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.
- Implementation efficiency - Your programs are expected to be
reasonably efficient.
- 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.
- Readability - Use intelligent naming for variables and functions.
- Indentation - Indent the code properly.
- 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.
Maintained by
Efi Fogel.
Last modified: February 29 2004.
|