Game : Design Checklist
Programs must be written for people to read, and only incidentally for machines to execute — Harold Abelson and Gerald Jay Sussman from Structure and Interpretation of Computer Programs
Good design cannot be achieved by simply following a formula. Although people will often make lists of good design "rules", the reality is that good designers will occasionally break the rules for good and appropriate reasons. In this class, you will be asked to design code that has three basic characteristics:
- Communication: Is the code easy to read and understand?
- Modularity: Do your classes have a small, well-defined purpose?
- Flexibility: Does you program contain duplication of any kind?
To help you stay focused on these goals, each project will provide a checklist of concrete things you can do in your code to help move you towards good design. Even if you follow all the items on the checklist, it will not guarantee your code is well designed — just that it does not contain basic mistakes made because you did not make proper use of what you know. These items may not cover every possible instance and sometimes you might have good reason not to follow an item to accomplish the higher level goals (if you do so, you must document the reason within your code — a good reason for comments!).
Guidelines
- Communication
- Use meaningful names: give variables, methods, classes, and packages non-abbreviated, intention-revealing names
- No magic values: use named constants for all specific values used multiple times or in program logic
- Write readable code instead of comments: use comments only to explain important design decisions or purpose of code, not to restate code logic
- Modularity
- No public instance variables: keep implementation details of your class hidden from the public interface
- No static variables: there should be no reason for shared global public state
- Flexibility
- DRY: no duplicated code, either exactly (from cutting and pasting) or in setup ("boilerplate" code)
