Last Updated 2015-03-05
Do not lock on integer objects, they are a special class.
Be sure to spend enough time in class design, Naming fields & methods. With good design/naming, a person who does not know anything about the project should be able to understand the code even without comment. (i.e. class Version1 => cannot understand what it does without comment, class FindUSBound => User can guess what it is without reading the comment)
I suggest to break down classes according to its functionality, not by version. For example, when I did project 3, I had a class named FindPopulation(census, query, upB, lowB) that computes population in parallel, and it has static sequentialCompute(census, query, upB, lowB) that can be used for sequential computation. I designed other classes similarly (with consistent naming convention, Find... + sequentialCompute) so that it looks consistent throughout the project.
One class per file. Unless the inner class is small class that belongs to outer class (like ListNode of LinkedList)
Each class/method should be doing one thing.
Having too many parameters to constructor/methods is warning sign (group parameters in small struct like Result, make sure your class/method is not doing too many things)
Use descriptive, informative plots. Don't focus on individual trials, rather focus on the trend. These are the results for the week 7 section parallelism:
Questions 6,7,8: We expect to see very thorough interpretation of the result. Your plot should be chosen appropriately to display the key points of the result.