Remember a program or a function should do one thing and one thing well. You should start to write good readable code from the start. Break your programs into meaningful functions. Be defensive when dealing with user input. Exit gracefully and if an error has been encountered – IO failed – inform the user in a meaningul but not verbose way – remember the flip side: silence is goldern.
Defensive coding: you should always assume that the user will enter incorrect input. So how are you going to deal with it? Tips: make sure you check the number of parameters entered against what you expect and their correctness.
Modular code: beakdown your code in to meaningful functions, e.g., convertAddress(). Make it more reabale. Reusable, easier to test and debug.
Exit gracefully: clean up and inform the user, assert conditions.
There is the detailed rubric:
Correctness 70%
– Is the program correct (i.e., does it work) and error free?
WARNING: DO NOT SUBMIT SEGFAULTED CODE:
In all cases below there is no grade given for a program that segfaults. A student will be asked to resubmit their segfaulted code. The resubmitted code will be graded out of 50% of the original grade. This is a significant penalty so make sure that you double check that your code compiles correctly and runs correctly without segfaults. Make your code is defensive to incorrect user input.
1. echo 17.5%
– cannot do the -n switch. -5%
– edge cases (e.g., does not work when have space in the string, no text). -2.5%
2. network 17.5%
– does not work in either mode (not simple bitwise operation errors here, i.e., too much errors in a specific mode). -7.5% for one. -15% for both.
– does not pass input check in interactive mode(long ip address). -3%.
– Logic error. e.g., cannot get right conversion from prefix to mask. etc. -4%.
– Input check in commands.(cannot handle well dealing with other characters) -2%.
3. sort 17.5%
– incorrect numerical sort -3%
– incorrect lexicographical sort -3%
– incorrect unique sort -3%
– incorrect reserve sort -3%
– wrong order for each of the four modes -3%
– input checking (wrong switch, valid file) -2.5%
4. rps 17.5%
– algorithm errors (e.g., error in stats, error in judge) -5%
– system errors (does the state machine work correctly) -5%
– no file decomposition (no head files or all-in-one) -(10,20)%
– weak handling on incorrect inputs(undefined or long inputs) -5%
Clarity (1-10) 10%
– Is the code easy to read, well commented, use good names
– for variables and functions. In essence, is it easy to understand and use
– [K&P] Clarity makes sure that the code is easy to understand for people and machines.
– Too much mysterious variable names with comments -5%
Simplicity (1-10) 10%
– Is the code as simple as possible.– [K&P] Simplicity keeps the program short and managable