Here are some coding tips, and details about grading programming assignments.
Here is some general programming project advice.
Give me six hours to chop down a tree,
and I will spend the first four sharpening the ax.
- Abraham Lincoln
This is true in coding as in chopping.
Resist the urge to start coding right away.
Spend 90% of your time preparing, and 10% coding, and you will spend
less net time!
Attempt to spend 10% preparing, and 90% coding,
then you may end up never understanding, and frustrating yourself,
wasting your time
If I want to learn a new protocol, language, etc.,
then I spend 90% of the allotted time on learning (studying),
and 10% on producing the product (the assignment).
Time pressure can get to one’s head, encouraging the opposite,
trying to complete the product first, before learning.
Resist that urge!
The time to complete each of these typically takes 2-5 hours for a
top-30% grade student,
about 10-25 minutes for myself, and maybe 30 min-1 hour for my
TAs.
Spend time on preparation not production!
Spend time enjoying learning the material,
not anxiously getting through through the assignment!
After all, programming is mostly thinking:
https:/agileotter.blogspot.com/2014/09/programming-is-mostly-thinking.html
Each function should do one small thing, and one small thing
only!
https://en.wikipedia.org/wiki/Unix_philosophy
This aids in the next goal:
Develop your classes and/or functions one small chunk at a time,
starting from the simplest.
Move to the next function only after the previous one has been
tested.
Trying to code a whole class, and then remove the bugs afterwards,
will likely prove to be too big a task.
Print plenty of status messages to track the progress of your
algorithm implementation.
Remember to comment them out before submission.
All of the functions in provided files must be completed as
directed.
Carefully read the comments and types of each member function,
noting both return values and output statements (they are not the
same!).
Check that your functions all have the right argument inputs and return
outputs,
even if they also have outputs to the screen!
Exception:
When the code is different from a comment,
the code is likely correct!
Assignments will be graded on their correctness, efficiency, style,
and more.
Complete and correct output for every test input case is necessary for a
full score.
A non-compiling, non-running, or crashing program or script
(segmentation fault, core-dump, syntax error, etc.)
will only receive points according to which tests pass.
We design unit tests so that one can crash and the rest can
succeed,
so that you can get more points.
If a program compiles and/or runs,
then points will be given for each incorrect test case or output.
Points may be deducted for:
Incorrectly formatted output. (Presentation Error),
Memory Leaks,
Specific types of inefficiency,
File format issues,
Any other errors that interfere with run-time or output.
Good programmers don’t always have good comments,
but they usually have clean, consistent, readable code style and
formatting…
Take pride in your code!
If your assignment is in Python, Bash, C++/C, Haskell, or Rust,
we grade your code using auto-formatters like:
black, shfmt, clang-format,
ormolu, or rustfmt respectively.
Changes to function names or parameters may mean we cannot properly
grade that function,
and you may not receive any points for it.
Do not edit any header files, unless we say so explicitly!
If there is any doubt, do not edit the header files or function header
types.
Check that file names match requirements and/or have not been
changed.
Your program should compile and run in the specified Linux
environment.
It is expected that all of your work runs correctly,
in the specified Linux environment we are working with in class,
in the exact manner we specify in the assignment description.
If you were contracted to write code for a job, and it ran on your
computer,
but not your employer’s as they needed, your work would be considered a
failure.
In that light, you are also responsible for submitting all text and
source files,
such that they are compatible with our specified environment,
e.g., encoded UTF-8, Unix delimited, etc.
Test on the desired platform (class container)!
Your tests may pass on your computer, but not the class CI/CD
container.
Stick to local IDEs that are Linux compatible, for example within the
class VM.
Use the supported language and version
(e.g., python3 not python2,
gcc-c++ not MS-visual-studio C++)
Files should be in UTF-8, Unix/Linux delimited
(which if you used the class Linux environment,
without copy-pasting from your host OS, you should be fine).
The test cases we will run for grading may be more extensive than any
fixed sample input we give you,
for example by using a randomized unit test (which you can still
see).
It is possible, even likely, that if your program seemingly works
perfectly,
for example with an input file: sample_input.txt,
that it may not work perfectly with our grading scripts or random unit
tests;
this is fair and reasonable challenge,
since we describe the bounds of performance required generally;
when coding in the real world for a job,
you will be expected to anticipate edge cases, weird behavior, larger
than expected data-sets, etc.
Practicing this can help you train one of the more important skills of
an industry programmer.
You should manually try some failing test cases yourself, that have
input and output,
perhaps different or which exemplify some edge case.
It may also help to build your own simple test cases.
Did you check the program with more input / output test cases than we
gave you,
by generating your own?
In the real world, and in industry, most of code is tested by
code.
When a networked program, or an operating systems program, or a web
program,,
does not have perfectly spaced output, it does not work, at
all...
Computers are not flexible; they are rigid, and they need babying!
Code that is merely run-able (playable, produces output, etc.)
is NOT correct code!
Getting workable code is the first half of the assignment.
Getting your workable code to be correct in all the remaining needed
details,
is the second half of the assignment.
Correct student code (yours) is:
matching the desired outputs,
AND does not crash,
AND uses the desired mechanism
(not just copy-pasting outputs, hard-coding outputs, or tricking
auto-graders,
which is blatant cheating).
Correct auto-grading code (ours) is:
code that verifies that student output matches or does not match
expected output
(some of the autograding code is actually fairly shallow and easy).
These are operationally enforced by the autograder:
ClassroomCode.html