Home | Learning Goals | Schedule | Administration | Readings | Lab/Lecture Notes | Assignments | Computing | UBC Connect |
Robustness: Your primary task is to create a working, robust program. This means that your program should produce correct answers on all legal input and produce comprehensible error messages on invalid input. Keep in mind that (unless otherwise mentioned) unreasonably long running time is probably an error.
How should you ensure robustness? We use the Google Test (and Google Mock) testing framework to help you reach that goal. You should ensure that your tests adequately exercise each function and ideally test overall program performance. In addition, you should complete the following Unpatented Steps to Robust CodeTM in succession on a Linux ugrad.cs.ubc.ca servers (like lulu.ugrad.cs.ubc.ca) before submitting your code:
-Wall
flag enabled. (Notify us of errors in our code.)
Coding clearly: You should always make an effort to write code that is easy for other people to read. In the real world, this is an important skill that is valued higher than cleverness or using the least number of lines/characters possible. In this class, it is important so that we can understand your program and grade it fairly. By reading through your code and comments, we should be able to figure out how your code is organized and why it works. If we can't, we reserve the right to deduct marks.
In the real world, most large (and many smaller) companies enforce
specific coding style guidelines. Some recent instances of 221
have enforced
Google's C++ style guide
,
which is an example of a good style guideline. We won't force you to
code that way (and specifically, we tend to use C++'s stream-based I/O
instead of C-style scanf/printf), but it's a good way to learn good style.
You may also want to check that your code cleanly passes
Google's lint
program run as cpplint.py
--filter=-readability/streams
, which checks for common
coding and style mistakes.
Speed: As long as your program takes a reasonable amount of
time, we will neither dock points nor give bonus points on the basis
of speed. In other words, all of your data structures should have the
expected asymptotic time and space complexity, but the constants will
not generally matter. Robustness and clarity come
first! If you're curious about how to make programs run
blazingly fast, talk to us, and we'll give you some tips and
tools. (Here's a freebie: never optimize any piece of code until
you've tested your program's speed and discovered that that code is a
bottleneck. Here's another: use a profiling tool like
gprof
to find and improve your bottlenecks; don't just
guess where they are!)
Working Individually vs. with Partners: All of the programming projects this term will be designed to be completed in groups, normally of two. If you choose to work on a programming assignment individually, you may still collaborate as described in the course syllabus (cite the individuals you work with in your README.txt file). However, we expect that all of these assignments will be easier completed in groups!
Ideally, we view group work as a way for people with complementary skills to tackle the problem together in order to learn more effectively and to deal with difficulties in the development process, bugs in their code, or problems with UNIX/g++. Two heads are often better than one in these situations! Our expectation is that all group members will work on the program together rather than dividing the program into parts and sewing the parts together the day before the project is due.. but you are allowed to do this (strongly discouraged but allowed). For those of you who decide to work in a group, here is what we expect of you:
We firmly believe in the value of collaboration. The above rules are intended to ensure that all group members learn from the work. If you have any questions or problems with these policies, let us know (but do NOT violate them) or simply work by yourself.
Your Makefile may support handin directly. Read the assignment documentation for more info.
Programming projects will be submitted electronically using the
handin
tool by 9PM on the project due date. Late work
will not be accepted. Only one group member should handin the code!
We may be flexible with due dates if you contact us well in
advance of the original due date.
Include all code files and header files required to compile and run
your project in your submission. Also, include any other files (such
as sample input) necessary for correctly running your program. Among
these should be a CMakeLists.txt
which will correctly
build, compile, and link your code when we run "cmake" and then "make"
and test your code when we run "make test"! Do not send executables,
or sample output. Finally, of course, include a README.txt
file which describes your submission.
Generally, the contents of the README.txt will be described on the assignment writeup, but here are items that should always be included:
To use handin
, place all the files to be submitted in
the directory whose name is:
~/cs221/NAME
where NAME
is the name of the assignment (e.g., assign1
, proj1
, assign2
, ...).
For instance, to submit proj2
, student
r2d2
would first (if necessary) create a directory
called cs221
in her.. his.. its home directory by
typing the following commands at the prompt in the Xterm window from
its home directory:
mkdir cs221
It would then create the proj2
subdirectory by
typing the commands
cd cs221 ; mkdir proj2
After placing the files containing its solutions for proj2 in the directory
~/cs221/proj2
created in the previous steps, r2d2
would then run the handin command while in its home directory:
handin cs221 proj2
After you have submitted your assignment, always
verify that the handin was successful using the
-c
option to handin.
handin -c cs221 proj2
If you want to overwrite an already submitted copy of your assignment, you can do it
using the -o
option:
handin -o cs221 proj2
You can use the -o
option as many times as you
like. Submit your work well in advance of the deadline, even
if it is not yet finished, and then overwrite the submission
regularly until you are ready to handin the final copy. This
will prevent you from getting in trouble if your computer or
the network connection dies right before you submit your
assignment. Note that you can not overwrite your submission
after the deadline has passed.
Did you know that you can access your lab account from your own computer? If you are on Windows, simply install XManager. You'll be able to use Xshell like a UNIX terminal in the lab, and Xftp to transfer files. If you're having trouble figuring out how to do this, use the discussion board or contact the staff.
Mac OS and Linux users have a built in Terminal where they can run programs to access our servers. Logging into your CS user account can be done like this:The
ssh -Y r2d2@remote.ugrad.cs.ubc.ca
-Y
option enables graphical programs to be run remotely, such as emacs
.
(If you are on a Mac, you will probably have to install
X11 first to get that GUI stuff to work.)
To transfer files to your account on our servers in preparation for a handin
,
you can use ftp
or scp
.
For example:
Don't forget the colon at the end!
scp source-file r2d2@remote.ugrad.cs.ubc.ca:
You may also wish to try Web Handin. But.. does your code work properly on lulu.ugrad.cs.ubc.ca? Web Handin also tends to mess up directory structures, so we would prefer you to use XManager.