How to Write a Coding Assignment Report — CS & Software Engineering Guide

What Markers Actually Assess

Most students assume a coding assignment is judged solely on whether the code runs correctly. In reality, a typical CS assignment rubric looks like this:

Component	Typical Weight
Correctness (code produces expected outputs)	30–40%
Code quality (structure, readability, style)	15–20%
Documentation (comments, README, docstrings)	10–15%
Testing (test cases, coverage, edge cases)	10–15%
Written report (algorithm explanation, analysis, reflection)	15–25%

This means code that works but is undocumented and unaccompanied by a report can score 40–50% — a pass, but not a distinction. Strong documentation and a clear report push a good solution into the top grade band.

Code Documentation

Inline Comments

Comments explain why, not what. The code itself shows what is happening; comments tell the reader why a particular choice was made, especially when it is non-obvious.

# Good comment — explains a non-obvious design decision # Using a max-heap instead of sorted list: O(log n) insertion # vs O(n) for sorted list, critical for large n in this context heapq.heappush(priority_queue, (-priority, item)) # Bad comment — just restates the code i = i + 1 # increment i by 1

Docstrings

Every function and class should have a docstring that describes its purpose, parameters, return value, and any exceptions raised. Follow the convention used in your language:

def binary_search(arr: list, target: int) -> int: """ Search for target in a sorted array using binary search. Args: arr: A sorted list of comparable elements. target: The value to search for. Returns: Index of target in arr, or -1 if not found. Time complexity: O(log n) Space complexity: O(1) """

Follow a consistent docstring format. Python: Google style, NumPy style, or Sphinx/reStructuredText. Java: Javadoc. C/C++: Doxygen. Your module may specify a particular format — use it consistently throughout the submission.

README File

Every coding submission should include a README file. It is the first thing a marker reads. A good README covers:

Project title and brief description — what does this code do?
How to run the code — exact commands, including language version and dependencies
Dependencies and installation — list all libraries with versions; include a requirements.txt or equivalent
Input format — what does the program expect as input?
Output format — what does it produce?
Example usage — a concrete run-through with expected output
Known limitations — what doesn't it handle yet?

Need help with your coding assignment?

Our CS and software engineering specialists help with implementation, documentation, testing, and the written report component.

Get Help Now →

Testing

Tests demonstrate that your code works correctly — not just for the given examples, but for edge cases and boundary conditions. Most CS markers read the test suite as part of the assessment. Include:

Unit tests: test each function in isolation with known inputs and expected outputs
Edge cases: empty input, single element, maximum size, negative numbers, zero — whatever is relevant to your problem
Boundary conditions: test at the exact limits (first element, last element, array of size 1)
Integration tests: test that components work together correctly

import unittest class TestBinarySearch(unittest.TestCase): def test_found(self): self.assertEqual(binary_search([1, 3, 5, 7, 9], 5), 2) def test_not_found(self): self.assertEqual(binary_search([1, 3, 5], 4), -1) def test_empty_array(self): self.assertEqual(binary_search([], 5), -1) def test_single_element_found(self): self.assertEqual(binary_search([7], 7), 0) def test_first_element(self): self.assertEqual(binary_search([1, 3, 5, 7], 1), 0)

The Written Report

Many coding assignments require a separate written report. Even where not explicitly required, a short accompanying document explaining your approach significantly improves the mark. Structure:

Problem statement: what was the problem and what were the requirements?
Design decisions: what data structures and algorithms did you choose, and why? What alternatives did you consider?
Algorithm explanation: a high-level description of how your solution works — pseudocode or flow diagram if helpful
Complexity analysis: time and space complexity of the key algorithm(s), with justification
Testing: what test cases were used, what they cover, and what the results were
Limitations and future work: what doesn't the solution handle? What would you improve?
Reflection: what did you learn? What was difficult?

Algorithm Complexity Analysis

Markers of algorithms and data structures courses expect Big-O analysis. Always state and justify the time and space complexity of your solution:

Complexity	Name	Typical scenarios
O(1)	Constant	Array index access, hash map lookup (average)
O(log n)	Logarithmic	Binary search, balanced BST operations
O(n)	Linear	Linear search, single-pass array traversal
O(n log n)	Linearithmic	Merge sort, heap sort, efficient sorting
O(n²)	Quadratic	Bubble sort, nested loops over input
O(2ⁿ)	Exponential	Brute-force subsets, recursive Fibonacci

Code Quality Standards

Meaningful names: calculate_mean(values) over calc(x); user_count over uc
Single responsibility: each function does one thing — if a function is more than 20–30 lines, consider splitting it
No magic numbers: use named constants (MAX_SIZE = 1000) not bare literals scattered through the code
Consistent style: follow PEP 8 (Python), Google Java Style Guide, or whatever your module specifies
No dead code: commented-out blocks, unused imports, and unreachable code reduce readability and suggest poor version control

Common Mistakes

Submitting code that doesn't run: always test a clean checkout of your submission before submitting — dependencies missing, path issues, and import errors cost significant marks
Comments that describe what, not why: # add 1 to i is useless; # offset by 1 for 1-indexed input is useful
No edge case testing: testing only the happy path misses cases markers will definitely test
No complexity analysis: stating "my algorithm is fast" without Big-O is not analysis
Hardcoded file paths: open("C:\\Users\\Don\\data.csv") will break on every other machine — use relative paths or command-line arguments

Frequently Asked Questions

How many comments are too many?

Comment density should match code complexity. A trivial getter function needs no comment beyond a one-line docstring. A complex dynamic programming recurrence or bit-manipulation trick deserves several lines of explanation. Aim for comments that would help a competent programmer who doesn't know your codebase — not someone who has never programmed.

Should I use AI tools to help with my coding assignment?

Check your institution's academic integrity policy. Many universities now allow AI assistance for coding but require disclosure. Using AI to generate code you cannot explain in a viva or oral exam is high-risk — if the marker asks you to walk through your code and you cannot, that is a serious academic integrity issue. Use AI tools to understand concepts and debug, not to replace understanding.

What if my code is incomplete — should I still submit a report?

Yes. Always submit the report even if the code is incomplete. A report that honestly describes your approach, the algorithm you intended to implement, the tests you designed, and what you did achieve can earn marks for design, testing, and reflection — even if the implementation is partial. Never submit nothing; always submit what you have with a clear account of its status.