Report the total number of lines in your code (wc -l) and estimate the percentage of these that are comments. Report the total number of lines of documentation (README, DESIGN, CHANGE_LOG, TIME_LOG, BUG_LOG, etc.)
username TAB TOTAL_LINES TAB number
username TAB COMMENT_LINES TAB number
username TAB DOCUMENTATION_LINES TAB number
username TAB MEM_USAGE_MB TAB number
username TAB CONFIDENCE TAB number
README - Should be well organized!! Someone completely unfamiliar with
this project should get a clear idea of what is contained in
all the other files. It should also give an overview for developers
of the purpose of the code, major design decisions (like data
strutures used, how a word is defined), the relationship of the
source files, how to compile, major problems that remain (small
bugs go in the BUG_LOG but if there are major problems those
deserve a place in this top most file.
Think "what would I want to know if I was supposed to maintain/extend
this code and I was seeing it for the first time". Don't forget
simple things like your name and contact information. It should also
contain a bibliography/acknowlegements section.
Describe how to compile for various
platforms, for testing, for debugging, for performance, ...
MANPAGE -Should describe clearly how to use the exectuable. You should
describe all command line options and give examples of use.
You should also define a words and give examples. Mention any
major limitations.
It is ok if you repeat some information from other files -give the
*user* everything they need to know here. Don't make them
chase the other documentation.
It should also be well organized and easy to read!
Makefile - Don't forget to have a make clean that removes all .o's
the executable, core and any gprof files etc.
TIME_LOG - Should contain both per assignment data and cummultive data!
Be sure to follow the requested format exactly!!!
BUG_LOG - Track bugs found and fixed. If you did not track as you
went try to remember what bugs took you a while to find.
Come on, I know you all had some and that they did not
just occur on 9/15 :-)
CHANGE_LOG - Describe features of each version roughly
for each assignment (versions 1-6 ?)
TESTPLAN.username
TESTING.WHITEBOX.username
TEST_LOG
TUNING - Refer to homeworks for details on these files.
Source code
Do not resubmit your testcases. The class test suite will serve as our final record of those submissions.
Go back over comments on your homeworks and comments to the class as a whole and incorporate changes into these files.
To get you started, I have set of questions.
I would like you to test your code both under Solaris on crux and under Linux on the ITL machines. Make any modifcations necessary to make the code run both places. (Getting it to run on Windows would be another great exercise!)
You may be able to produce a single version of the code that will run both places. However, often when porting code between platforms (especially code that relies on special libraries or a non-standard system call interface), this is impossible. In cases like this, in order to maintain a single code base, developers often introduce conditional compilation information into their code. For example:
#ifdef SOLARIS code that works only on Solaris #endif #ifdef LINX code that works only on Linux #endif #ifdef WINDOWS code that works only on Windows #endif
Such defines can be turned on and off in your Makefile. For example:
#PLATFORM=LINUX PLATFORM=SOLARIS CFLAGS=-D$PLATFORMThis is a technique you can use if you find it necessary.
Create a file PORTING and describe any problems you ran into while porting your cs450words program and how you resolved them.
I highly recommend that you take a look at GNU's word count program, wc . Even better download all of the GNU core utils (includes wc among other things)and try to build them and understand the wc code.
If you do download it, look for the test cases, the #defines, the argument processing. See if you can find the definition of a word.