CompSci 108
Spring 2010
The Software Studio

Bins: Code Critique

This project is intended to help you to learn to critically read code, understand its purpose, and identify ways to improve it. Along the way, you should start to build a sense of what makes one piece of code better than another given a specific set of design goals.

A Code Fragment

Look at this handout given previously as an assignment in CompSci 100. Start by reading it and making sure you understand the problem you are being asked to solve. Next, examine the code given as an exemplar for solving the first part of the assignment and describe its strengths and shortcomings. In your project analysis, answer the following questions:

A Complete Program

Now, look at this complete Java solution to the same problem. Start by reading it and making a list of any questions you have about how the code works. Next, examine the code from the perspective of how it may be extended in the future. In your README, answer the following questions:

While studying this code, please note any good things about the code, that you might keep in the final version as well as problems with the code.


Refactoring is the practice of updating a program to improve its design and maintainability without changing its current functionality significantly. An example of refactoring is creating a single function or class that replaces two or more sections of similar code because it reduces the amount of redundant code within the program and makes the code easier to debug and test. You should examine the given program and refactor it based on your critique and our discussion in class. You may create (and comment) any new functions or classes you want to help improve the program; however, you must justify each change you make by explaining specifically how it improves the code.

Additionally, you should provide a set of tests that verify your modified program still works as intended. Tests can be in the form of input data files, unit tests, or a separate driver program that verify every line of code written works as intended. Your tests should be documented as to their purpose, i.e., how does these input values relate to the written code.

Note, in the given code, there is one known bug, one potential bug not exploited in the current version of this program, and one kind of numeric input value that the program arguably does not handle properly.


Finally, using your refactored code, you should add three additional bin packing algorithms:

For extra credit, also change the program to print the algorithm that produces the smallest sets of disks required to fit all of the files. In case two algorithms produce the same number of disks, the first algorithm tried should be the one printed.

Grading Criteria

Your grade will be determined primarily by how well you justify the changes you make to the code rather than simply how many changes you make. In other words, if you feel strongly that the code is perfect as is and make no changes, you can still get an excellent grade if you completely justify why the code does not need to be changed in the context of your design objectives. On the other hand, you can also decide to scrap the code entirely and start over from scratch but, again, you must clearly justify your decisions and why the submitted code is better than the original. Justifications that refer specifically to principles given in the resources below will be given higher credit than those that use terms like "clearly/obviously", "good/sucks", or "like/hate".


The following readings provide principles for improving the design of the code.