Project evaluation criteria

From Inforail
Revision as of 05:28, 27 April 2011 by Alex (Talk | contribs) (1 revision)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The following criteria will be used to determine the quality of your work. Their purpose is:

  • to make it easier to separate the excellent works from the good ones;
  • help the authors of good projects create excellent ones in the future (which is easier when you have a clear definition of "excellent").

This is a draft, the rules will continue to evolve, therefore you should come back to this page every now and then.


  • Matching the requirements - each assignment includes a set of requirements, you have to implement all of them; you can add extra features if you think they are appropriate, but think twice before not implementing a required feature or deciding to implement another one instead of it.
  • Design of the code
    • Reusability - the project must be split into modules (classes, structures, functions, etc) properly, enabling you to reuse the functionality without having to copy/paste code. Examples of red flags - repetitions of the same code, the use of hardcoded values, the inappropriate use of global variables, etc. Think about the future, try to design the program in such a way that if you are told to add a new set of features to it, you will have to add new code, without rewriting existing code.
    • Readability - proper formatting is one thing, informative variable names is another. What else? Proper indentation, using whitespace to aid readability.
    • Correctness - absence of bugs (ex: memory leaks, off by one errors, uninitialized variables, etc) poor memory management, forgetting to close handles, etc.
    • Reliability - if you fail, fail gracefully; if you can predict the possible errors - handle them. For example, an HTTP download manager that verifies the return codes and checks the details given in the server's response is better than one that blindly hopes that the server returned the expected results, that the connection will be persistent, etc.
  • Presentation - you must be able to explain how your program works, demonstrate its features, show it in action, etc;
  • Q&A session - you must be able to answer questions related to your source code, as well as to the materials that were used in the development process;
  • Timing - a project must be submitted before the deadline; overdue projects will be penalized.


Tip: one of the best ways to learn to write good code is to read Steve McConnell's Code Complete; this book is an excellent guide.