****REPORT****

Some general remarks:

The point of measuring LOC is not for the purpose of reducing it in the future.
Like some of you mentioned, low LOC can actually reflect code with low
readability/portability.  However, this is not in contradiction with PSP!
PSP simply uses LOC as a measure of size, not as a reflection of code quality.

Scope of PSP:  The goal of PSP is to improve your efficiency through
measurement. Thus, suggesting that PSP should provide a framework for automated
testing is outside the scope of PSP.
Similarly, it is outside the scope of PSP to create a searchable and documented
code repository.

Statements like "If we perhaps removed {insert some feature of PSP here}, then
it would improve the process"  are not very meaningful.  There are reasons why
it is part of PSP in the first place, so you need to make
an argument against those reasons.

To get an 18 or 20, you generally had to make an interesting insight/proposal
and make a good argument for it.


Codes:
R1:  Spelling/Grammar is unacceptable.  This is not an English class, but part
of developing software is effectively communicating with your team.  If your
mistakes get in the way of clarity, then you were marked down.
For example, using fragments or run-on sentences was the most common mistake.

R2:  Thoughts not clearly expressed/organized on paper.  The logical flow of the
report was confusing; ideas were brought up but not explained; everything was
one big paragraph; etc...

R3:  Interesting insight/proposal!

R4:  You are stating the obvious.  For example, describing the purpose of PSP as
an introduction to your report is unnecessary.

R5:  The suggestions were based on things that were in PSP0, not PSP0.1.  You
were not marked down for this, but you generally received more points if you
made suggestions for improvements on new things like LOC counting than on older
things like defect recording.

Note:  You may have been marked down for one of these things, but the code may
not be written down on the paper.

CODING/TESTING

Tests T1-T4 are for very basic functionality, and correspondingly have a heavier
influence on the marking then the others.  The same goes for running the program
on all three assignments.


For the corner cases, some of you made assumptions that eliminated some of the
corner cases.  However, your program should test them anyway, even if it gives
the wrong answer, because these cases may occur later on and you need to know
how your program will handle them.


T1:  Test for simple comments (// or /*..*/ on one line)
T2:  Test for empty lines
T3:  Testing for correctly breaking apart a file into functions, with more than
just one function.
T4:  Testing for multi-line comments

T6:  Corner cases.  These include, but are not limited too:
* // or /* or */ inside of quotes should not be counted as comments
* function declarations should not count as functions
* nesting of brackets.  For example, havin a multiline if statement inside of a
function.
* brackets inside of comments/quotes should be ignored
* typedef/struct constructs should not count as functions.
* defining of multiple functions on one line, or having one function header be
spread over a few lines.

T5:  Your testing did not involve simple, broken down test cases.  Running your
program on the three assignments was not enough.  You needed to isolate the test
cases in separate files or separate functions, that way the program validity can
be easily verified for the different cases.  Of course, some of the test cases
can be combined into the same file, but in a way that makes it clear what is
exactly being tested at which point.

T7: You did not follow instructions on presenting the results of your tests.
Some people didn't run the program on the first two assignments at all.  Some
people ran it, but did not present their results in a clear table form.  (It
doesn't literarly have to be a table--something that is clear visiually
would suffice.)  Some people only showed the LOC count for the whole program,
not for each function.

T8: You needed to include a printout of the test cases you used.  If you didn't,
then you needed to be very specific about describing the cases you tested.

T0: Your program does not agree with the specifications of the assignment.  For
example, you cannot assume that you don't need to handle multi-line comments.