http:^^www.cs.wisc.edu^~cs367-2^cs367.html

来自「This data set contains WWW-pages collect」· HTML 代码 · 共 570 行 · 第 1/2 页

Sorting                         lecture #17     405-432
---------------------------------------------------------------------------
To be announced

</pre>

<a name="photo">
<h2>Assignment 0</h2>
</a>
This is an
<em>
absolute necessity to get a grade other than F!
</em>
Bring in a photograph of you.
It should not be your picture from your 1st birthday, nor
should it be the one from that boy/girl scout trip in the summer
of 1984.
Other than that, it can be color or black-and-white, any size, etc.
<em>
No grade will be given without a photo!
</em>

<a name="assignments">
<h2>Programming Assignments</h2>
</a>
Proficiency in a programming language (Pascal, C, C++, or FORTRAN)
at the introductory level is assumed;  the equivalent UW-Madison prerequisite
course is CS 302.  
<p>
Assignments must be done in C++ on the designated machines.  These
are in the machine rooms on the first floor of the
CS building.  I encourage you to use these machines.
<p>
If you prefer to use a home computer, you may do so, with certain
restrictions: You must have a C++ compiler on your home machine; 
you must log on to your university account often to read email
and get copies of data files; finally, we will require that
you turn in your C++ program electronically (via email) so if you
work at home you must make provisions to download your programs to
your university account and to make sure that they compile and run
with the g++ compiler on the SPARCstations.
<p>
I often use electronic mail to notify students of changes in
assignments, hints for programs, etc.
<em>
I assume that you will read all
electronic mail that I send.
</em>
<a name="late">
<h3>Late Policy</h3>
</a>
<i>No</i> late assignment will be accepted.
Assignments <i>must</i> be turned in exactly when they are due.
In order to avoid lateness caused by machine loads, coincident due
dates for several classes, etc., simply be sure to get started right away on
each assignment.
Things are certain to go wrong now and then, so don't wait until the
last minute to start.
Any exceptions must be approved by me, and you will need a very good excuse.
If you get into trouble, see me as soon as possible.

<a name="cheating">
<h3>Cheating</h3>
</a>
The Computer Science department takes a <em>very</em> hard line
stance on cheating.
You are welcome to
communicate with each other on design of algorithms and data
structures, but
<em>
there is to be no sharing of code.
</em>
<p>
You are also expected to learn, understand, and obey the
<!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><!WA34><A HREF="http://www.cs.wisc.edu/csl/policies/">Computer Systems Lab Policies</A>
governing your computer accounts.
<a name="help">
<h3>Help</h3>
</a>
If you are having problems with the course work or programs,
please let me know as <em>early</em> in the semester as possible.  
<h4>Office Hours Policies</h4>
If you need help debugging a program, the best way to get help is to
visit any one of the
<!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><!WA35><a href="#tas">CS 367 TA's </a>
during his office hours, taking along a current
hard copy of your program.
My office hours are intended as a time for me to re-explain concepts
that I have presented in class but about which you are still confused,
or to answer your specific questions about course material.
I encourage you to use email as
a reliable way to contact me about any problems;  I read and respond to email
several times daily, almost every day of the week.

<a name="criteria">
<h3>Program Grading</h3>
</a>
Programs are graded on all of the following criteria.
<ol>
<li>
Correctness: The program should behave correctly/normally on typical
input.  The program should behave as stated in the project
specifications.
<li>
Clarity:  The program should be easy to read and understand.
(See the notes on <!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><!WA36><a href="#style"> style </a> below for more information
about clarity).
<li>
Robustness:  Correct behavior in extreme or unusual situations.
The program should handle such situations in a reasonable and
logical manner (that is, it should not simply blow up).
<li>
Quality of test data:  The test data for the program should
demonstrate all facets of the program's capabilities, including
unusual cases.  
<li>
Efficiency:  Avoid unnecessarily inefficient algorithms or constructs.
However, efficiency should never be pursued at the expense of clarity.
<li>
Modularity:  The program should be modular and should make effective use
of parameters.
<li>
Completeness:  You should incorporate all information into your 
program;  there should be no need for any sort of extra (paper)
documentation.
<li>
Generality:
The program should be as general as possible, subject to consideration
of efficiency and clarity.
You should avoid arbitrary limitations (such as a bound on the size or
complexity of the input) whenever possible.
When limitations are necessary, they should be expressed as defined
constants near the top of the program so that they can be easily changed.
The only numeric literals that should appear in your program are those
values not very likely to change (such as 0, 1, or 3.1415926535).
</ol>
<a name="style">
<h3>Style</h3>
</a>
<ol>
<li>
Use meaningful identifier names.
<li>
Use a consistent naming scheme for identifier names.
A suggested convention is as follows
<ul>
<li>
<samp> int variable_name; </samp>
<li>
<samp> int function_name(int argument); </samp>
<li>
<samp> const int DEFINED_CONSTANT = 1234; </samp>
<li>
<samp> enum EnumType { VALUE1, VALUE2 }; </samp>
<li>
<samp> class ClassName ... </samp>
</ul>
<li>
Do not put multiple statements on a single line.
<li>
Skip lines between functional groups of code.
<li>
Use a clear and consistent indentation style (see the DeWitt notes
for a suggested style).
<ul>
<li>
Indent continued statements (if, loops, ... etc).
<li>
Line up {'s and }'s.
<li>
Label }'s meaningfully (e.g.  ``<samp>} // while (!done)</samp>'').
</ul>
</ol>
<a name="external">
<h3>External Documentation</h3>
</a>
This should be included as a long comment at the beginning of your
program.  It is addressed to both the typical user and to someone
who wants to know superficially how the program works:
<ul>
<li>
<em>
Include your full name and student ID at the beginning of the comment.
</em>
<li>
Give a general description of what the program does.
<li>
Tell how to use the program: how to call it, format of data.
<li>
Give limitations, bugs, special features, and assumptions made.
Describe negative as well as positive aspects of the program.
If you don't include negatives we will assume you were unaware of them. 
</ul>
Information included in the assignment about the problem description
need not be repeated, but may be briefly summarized for the first point above.
A statement referring the user to the assignment document is then
sufficient. Note that this only applies to the problem description!
<a name="internal">
<h3>Internal Documentation</h3>
</a>
There are four main types of internal documentation:
<ul>
<li>
Headers:
Comments at the headers of functions, classes, and major data structures
should describe their purpose, assumptions about their parameters,
and the main outline of any algorithms they use.
<li>
Declarations:  Comments next to a declaration of a variable or data member
should provide extra information not conveyed by the identifier's
name.
The name of a variable should tell as much about it as is possible without
making it too long;
additional information can be supplied by a comment.  For example<br>
<pre>
   <samp>int top; // index of last element added to stack</samp>
</pre>
You should use comments to explain parameters as well as local variables. 
<li>
Within segments of code:  Tricky or opaque sections of code should be
avoided, but sometimes they are necessary.  In such cases, a comment
can help the reader understand what's going on.
<li>
Between segments of code:  These comments clarify the top-level outline
of your algorithm.
</ul>

<a name="misc">
<h2> Using Unix and Vi</h2>
</a>
Many people working with UNIX for the
first time will find that it takes some time to become
comfortable with it (this is particularly true if your
only previous programming experience is with Pascal using 
MacPascal on a MacIntosh.)  I strongly urge you to put in
the time early in the semester to become comfortable with
Unix.  While this time may be painful, it is time well
spent.
Also, you may wish to attend a UNIX tutorial.
They will be held in rooms 1240 Comp Sci in two sessions on each of the
following days: TBA
You will want to pick up a copy of 
<!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><!WA37><a href="#text"> CS 1000</a> before you go.

<a name="cycle">
<h2> The Program Development Cycle </h2>
</a>
The program development cycle in a UNIX environment is:
<pre>
<samp>
for (;;) {
    edit your program             // %vi program.c
    compile your program          // %g++ -Wall -g  program.c
    if (there are compilation errors)
        continue;
    run your program              // %a.out &lt; inputfile &gt; outputfile
    look at your output           // %vi outputfile
                                  // or %more outputfile
    if (there are no errors)
        break;
    if (you are too tired to continue) {
	print a listing to take home
                 // pr program.c inputfile outputfile | lpr
	goto home
    }
    debug the program
                                  // gdb a.out
                                  // run
                                  // ...
                                  // quit
}
you're done!  turn in the result
		 // submission instruction to be given out later
</samp>
</pre>

</BODY>
<ADDRESS>
<I>
<!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><!WA38><A HREF="http://www.cs.wisc.edu/~yannis/yannis.html"> [e-mail] </A>
<BR>
Mon Aug 19 17:28:14 CDT 1996
</I>
</ADDRESS>