Code Critique

This activity 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.

There are three parts to this activity:

• analyze and comment on a small fragment of code
• analyze and comment on a complete program
• refactor the given code to improve it

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 README file, answer the following questions:

• What specific pieces of code help versus obscure your understanding of the algorithm?
• What, if any, comments might be helpful within the code?
• Does it satisfy its role as a tutorial?
• What, if any, suggestions does this code make about the remaining parts of the assignment will be written?
• Based on your responses above, rate how clearly the code is written.

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:

• Does it satisfy the requirements of the assignment?
• What, if any, comments might be helpful within the code?
• What, if any, additional functions may be helpful?
• What, if any, classes may be helpful?

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

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 should justify each change you make by explaining specifically how it improves the code.

Improving

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

• random-order: shuffles the collection of files first before trying to the worst-fit algorithm
• increasing: sorts the collection of files in increasing order before trying the worst-fit algorithm
• your own packing algorithm: since the number of files is small, it can either use an exhaustive search to find the exact minimal solution or an approximate algorithm different from the other four implemented. Your algorithm does not need to be optimal, or even very smart, just different from the others.

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 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".

Resources

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

• OO in One Sentence by A. Hunt and D. Thomas
• Open Closed Principle by R. Martin
• Code Smells by K. Beck and M. Fowler