I chose to write down this post for the benefit of my students who submit projects in their courses and for the benefit of my assistants who mark projects submitted by my students.
There are many ways for evaluating a coding project submitted by students. The following is my personal suggestion. I will be more than happy to get feedback.
Program Executes as Expected (40%)
The optimal scenario is having unit tests that can be executed on every submitted project. This way the marking will be more accurate and fair for all projects. Alternatively, it is possible to agree upon a series of small tests and make sure the very same tests are checked on each one of the submitted projects. In order to keep the process transparent and accurate there is a need to prepare a detailed excel document that shows the exact small tests that were checked for each one of the projects and their results. Apart of this basic format test it is also common to check more things in this category, such as the following:
1. The program is user friendly. Users can easily navigate and use the program. Good program is a program that allows the user to start using it without getting into confusion and/or looking for help.
2. The user interface is accurate and clear. There are things we can certainly expect every develop to pay attention to, such as having all user interface widgets aligned with each other and having clear colors that allow a simple usage of the program (e.g. having text in blue with background in red damages the clarity of the program).
Code Review (30%)
Having a program that works is not enough. High quality coding practices implementation should be part of the project evaluation. Some of the common mistakes include the following:
1. The code is procedural while the programming language in use is OO.
2. The code doesn’t use the programming language special characteristics that aims at assisting us writing a better code (e.g. writing in C# without using properties, writing in Java while avoiding the benefit of using interfaces etc.).
3. The code is written inefficiently (e.g. writing a loop that includes a code that invokes a method that returns the same value is not efficient.. we could place the method invocation before the loop takes place).
4. The code doesn’t implement code reuse common practices (e.g. instead of declaring one detailed constructor and having all others using it the code includes code that repeats itself in each one of the constructors).
5. The encapsulation is damaged. Instead of having all members defined with private and allowing them to be accessed via properties (in C#) or setters & getters (in Java, C\C++ and PHP) the code includes many of its class members with an access modifier which is not private. On the other hand, in some cases it is certainly acceptable (and even expected) to have a member with the public access modifier (e.g. class Point that includes x and y members their values are not limited).
6. The code exceptions handling is not as good as it could be. One example is the bad practice in Java of catching exceptions using the general base type ‘Exception’ instead of using the more specific types. The outcome of doing is might be catching runtime exceptions.
7. The code does not follow coding conventions (e.g. defining a method that starts with a capital letter when writing in Java doesn’t look good and might cause confusion, defining a property in C# that doesn’t start with a capital letter might generate confusion…).
8. If the assignment detailed document lists a required design and the program doesn’t follow it the lose of points should be clear and significantly big.
Documentation (30%)
Writing code without documentation is very bad. Each programming language allows different types of comment. Writing in a specific programming language without writing documentation as expected in that specific programming language should cause a lose of points. Hereto few examples for loosing points due to bad documentation:
1. Code written in Java that doesn’t include API documentation.
2. Code written in C# without remarks in XML format.
3. Most programming languages allow us to add ‘//’ (C++ Style) remarks. These remarks should come before each and every code segment in order to explain its purpose.
4. Most programming languages allow us to add ‘ /*’ and ‘*/’ (C Style) remarks. These remarks should come in the beginning of the function body and should provide a general explanation about the algorithm that was in use when developing it.
