This Rubric should be used to guide your assessment of Trainees Coursework at CodeYourFuture
Details on how to mark coursework can be found on the documentation website
- The code achieves all of the tasks in the coursework [read more]
- The code achieves the task in an intended way and solves the "general" problem [read more]
- The code covers all edge cases [read more]
- The code does not contain any obvious bugs
- The code handles error responses as well as success responses [read more]
- The code follows a consistent style
- The code follows CodeYourFuture's coding standards [read more]
- The code is well indented [read more]
- The code uses good variable names [read more]
- The code uses good function names [read more]
- The code uses code which is easy to read and understand [read more]
- The code should not use hard coded values [read more]
- The code is divided into functions of a good size. [read more]
- Code is not repeated in several locations of the coursework. [read more]
- The coursework does not have commented out code. [read more]
- There is no dead code in the coursework [read more]
- There is no extra or debug logging [read more]
Completion of all of the tasks is an essential part of the homework.
If there are tests that you have to make pass, you should not edit them to make your code work. Doing so will mean you get marked zero for this section.
As well as completing all of the tasks, you should be sure to complete the task in a way that we are expecting and that covers all cases.
You should also always try to solve the problem in the "general" rather than in the "specific".
For example, we could set the challenge
Print every element of an array to the console Test 1: let array = ["A","B","C"] Test 2: let array = ["1","2","3","4"] Test 3: let array = ["Up", "Down"]
To make this test pass you could write
However, that would not work for every case that exists - only the ones that we're writing. Your aim isn't to just pass the tests, it's to write good code that solves the problem.
A better solution would be
Edge cases are when code does something you're not expecting and you didn't account for in your code.
Some edge cases are valid data, and some are not.
Some examples of valid edge case are that some names contain punctuation, or some people may only have a single name, which your code needs to be able to handle. An example of an invalid edge case is if someone doesn't enter a name at all, which your code should reject - if your code doesn't notice the problem where the user provides their name, other code you wrote may make assumptions which are incorrect.
See Falsehoods Programmers Believe About Names for some interesting examples.
Good code should handle all of these cases so that they can't happen - and if they do - they don't make your program crash or stop working.
Validations are used wherever necessary. The code never breaks under any circumstances. Especially under invalid inputs that come from the user end. Regardless of it being a negative, over-sized, invalid format, etc., every input passed should be processed, sanitized before taking it further. Every object is checked for its actual data existence before accessing its properties.
Writing small functions makes your code easier to understand and easier to work with. Ideally you should be able to describe what a function does in one sentence, without the word "and".
Good examples: "This function returns the user's favourite author", "This other function Tweets the title of an author's most popular book".
Bad example: "This function finds the user's favourite author and sends a Tweet with the name of that author's most popular book".
The code should not contain debug logging that was used during development. For example, any logs like
should be removed.
Not just the error messages, every response that is returned by the server must be properly handled. It should have necessary headers, response messages, error codes and any other necessary details attached with it in required format. All possible scenarios are tested to avoid timeouts, unresponsive UI, etc.
Duplicated code should be moved into functions so they can be reference from multiple places.
Having lots of duplicated code in your coursework means that it is harder to change or update your code.
Commenting out code is a great way to debug your code but when you use it to keep code for later it can become a problem.
Instead of commenting out code you want to keep but not use, consider moving it to separate file. This will make it easier to keep track of the code you're currently working on.
Having lots of commented out code make your code harder to read and make it easier for you to get overwhelmed and lost in your code.
Since we use Git to record all of the changes to our code you can always use the Git History to see everything that has changed.
Dead Code is code that is in your coursework but can't be reached or run by your program.
For example, a function that is never called is considered dead code.
Dead code should be removed from your coursework or re-written so it is used. Having lots of dead code in your coursework can make your work hard to read and understand.
All code written by Trainees at CodeYourFuture should follow our Coding Standard guidelines.
These guidelines are based on ones used in industry.
Guidelines are important in big organisations so that everyone writes code in the same way across a large application. It's important that trainees get used to writing in a consistent style early on.
Indentation is a fundamental aspect of code styling, and plays a large role in influencing readability. First of all, indented code is easier to read through than unindented code.
With unindented code, the overall structure of the code might be somewhat difficult to see. However, with indented code, the overall structure of the code jumps out at you. Tabs tell you that a line of code is inside a function, loop, if statement, or else statement. Knowing which parts of the code is inside what will become especially important when your code becomes more complex.
Good function names are important so that code is easy to read and understand what it is doing.
A bad function name might be
A good function name might be
Sometimes if you can't come up with a good function name it's an indication that the function doesn't have a nice, crisp focus and needs to be refactored.
But it's well worth the trouble finding the best possible names, since it makes your code so much more understandable and usable.
- Coding like Shakespeare: Practical Function Naming Conventions
- Trouble coming up with good names for functions
Each variable is named so it is clear which variable is being used at any time. It is important to use meaningful names for variables:
means that the variable
pocketMoney is being used to store how much pocket money you have. Right now you have £20.
The name given to each variable is up to the programmer, but ideally a variable name should have meaning you can understand without needing to read any other code, i.e. it should reflect the value that it is holding.
The most important thing when writing code is to make it easy to read and understand, and as simple as possible.
An example of write more readable code might be using a
filter instead of a complicated
for loop. This is better, because it is immediately obvious what you're trying to do - filter an array - and you're less likely to make a mistake using it.
Could be written like this be easier to understand and read.
As you can see, we've reduced six lines of code into one and it is immediately obvious that it is trying to filter the trees beginning with B.
Writing readable code is a big topic and one that you'll get better at as you go on. We encourage you to read more about it.
Hard coded values with no explanation make code hard to understand and read in the long term. For example
Will be hard to understand when you codebase grows.
Instead use constants to store your hard coded values - this means the value has a name, which can be usefully descriptive. For example