How to Write a Computer Science Assignment Report

TL;DR

• A CS assignment report is not just your code with comments — it's a written document explaining your work
• Include: problem statement, approach, implementation details, results, and analysis
• Explain your design decisions — why you chose that algorithm, data structure, or architecture
• Use diagrams, pseudocode, and tables to make your report clear and professional
• Don't paste walls of code into the report — show key snippets and explain them
• Follow your professor's specific format guidelines (they override everything here)

---

Why CS Students Hate Writing Reports

You chose computer science because you like solving problems with code. You didn't sign up to write essays about your code. Yet here you are, staring at a document that's supposed to explain your sorting algorithm implementation in 2,000 words.

Here's the uncomfortable truth: writing about code is as important as writing code. In the real world, software engineers spend significant time writing documentation, design documents, code reviews, and technical specifications. The ability to communicate your technical decisions clearly is what separates good developers from great ones.

Your CS professor knows this, which is why they're making you write reports. Let's make sure you can do it well.

---

The Standard CS Report Structure

Most CS assignment reports follow this general structure. Your professor might have specific requirements that differ — always follow their guidelines first.

1. Title and Header

Assignment 3: Binary Search Tree Implementation
Course: CS 201 - Data Structures
Student: Your Name
Date: February 27, 2026

2. Introduction / Problem Statement

What to include:

• What problem were you asked to solve?
• What are the constraints or requirements?
• What's the expected input and output?

Example:

This assignment required implementing a balanced binary search tree (AVL tree) that supports insertion, deletion, and search operations. The implementation must maintain O(log n) time complexity for all operations and handle duplicate keys by incrementing a count field rather than creating duplicate nodes.

Keep it concise — 1-2 paragraphs. Your professor knows the assignment; they want to see that YOU understood what was asked.

3. Approach / Design

This is the most important section. Explain HOW you solved the problem and WHY you made the decisions you did.

What to include:

• Your overall approach to the problem
• Which algorithms you used (and why)
• Which data structures you chose (and why)
• Any design patterns or architectural decisions
• How you decomposed the problem into smaller parts

Example:

I chose to implement the AVL tree using a node-based structure with explicit height tracking rather than a red-black tree for two reasons: (1) AVL trees provide stricter balance guarantees, resulting in faster lookups which are the primary operation in the test scenarios, and (2) the implementation complexity difference is minimal for this assignment's scope.

The tree is implemented using three main classes:

• Node: Stores the key, value, height, and child pointers
• AVLTree: Contains the tree operations (insert, delete, search, rebalance)
• TreeVisualizer: Utility class for debugging that prints the tree structure

This is where you demonstrate understanding. Anyone can write code that works; your report should show you understand why it works and why you built it this way.

4. Implementation Details

Go deeper into the technical specifics:

What to include:

• Key algorithms explained (with pseudocode if helpful)
• Tricky parts and how you handled them
• Key code snippets (selected, not entire files)
• Helper functions and their purposes

Code snippets should be:

• Short (10-20 lines maximum)
• Focused on the most important or interesting parts
• Accompanied by explanation
• Properly formatted with syntax highlighting (if possible)

Example:

The rotation operations are the core of maintaining AVL balance. After each insertion or deletion, the balance factor of affected nodes is recalculated. If the balance factor exceeds ±1, one of four rotations is applied:

def _rebalance(self, node):
    balance = self._get_balance(node)
    
    # Left-heavy: right rotation needed
    if balance > 1:
        if self._get_balance(node.left) < 0:
            node.left = self._rotate_left(node.left)  # Left-Right case
        return self._rotate_right(node)
    
    # Right-heavy: left rotation needed  
    if balance < -1:
        if self._get_balance(node.right) > 0:
            node.right = self._rotate_right(node.right)  # Right-Left case
        return self._rotate_left(node)
    
    return node

The four cases (Left-Left, Left-Right, Right-Left, Right-Right) are handled by checking the balance factor of the child node before performing the primary rotation. This ensures O(1) rebalancing per node visit.

5. Testing

What to include:

• How you tested your implementation
• Test cases (especially edge cases)
• Results and whether they match expected output
• Any bugs you found and fixed

Example:

Testing was conducted in three phases:

Unit tests: Individual operations (insert, delete, search) were tested with known inputs and verified against expected outputs. 24 unit tests were written covering normal cases, edge cases (empty tree, single node, duplicate keys), and stress cases (1000+ insertions).

Balance verification: After each operation, a recursive validation function checks that every node's balance factor is within [-1, 1] and that the BST property is maintained.

Performance testing: Insertion and search times were measured for datasets of 100, 1,000, 10,000, and 100,000 elements to verify O(log n) time complexity.

Operation	n=100	n=1,000	n=10,000	n=100,000
Insert	0.1ms	0.8ms	3.2ms	12.1ms
Search	0.05ms	0.3ms	1.1ms	4.8ms
Delete	0.12ms	0.9ms	3.5ms	13.4ms

6. Results and Analysis

What to include:

• What your program produces
• Analysis of complexity (time and space)
• Comparison with alternative approaches (if relevant)
• Limitations of your implementation

Example:

The implementation achieves the expected O(log n) time complexity for all operations, as demonstrated by the approximately logarithmic growth in execution time across dataset sizes. Space complexity is O(n) for the tree itself, with O(log n) additional stack space for recursive operations.

Compared to a standard BST (without balancing), the AVL implementation is approximately 40% slower for insertion (due to rebalancing overhead) but up to 300% faster for search operations on skewed datasets, where an unbalanced BST degrades to O(n).

7. Conclusion

Brief summary of what you accomplished, what you learned, and any remaining limitations.

8. References (if applicable)

Cite any external resources:

• Textbook chapters
• Online references
• Algorithm descriptions
• Stack Overflow answers you referenced

9. Appendix

• Full source code (if your professor wants it included in the report)
• Additional test results
• Screenshots of program output

---

Writing Tips for CS Students

Explain to a Technically Literate Reader

Your audience is someone who understands CS concepts but hasn't seen your specific implementation. You don't need to explain what a binary search tree is, but you do need to explain why you chose a specific implementation approach.

Use Diagrams

Visual representations are incredibly valuable in CS reports:

• Flowcharts for algorithm logic
• Class diagrams for OOP structures
• Tree/graph visualizations for data structure states
• Sequence diagrams for interaction flows
• Tables for performance data

Tools like draw.io, Mermaid, or even hand-drawn diagrams photographed clearly are all acceptable.

Don't Just Describe — Analyze

Description: "I used a hash map to store the data." Analysis: "I used a hash map to store the data because the primary operations require O(1) average-case lookup time. While a balanced BST would provide O(log n) guaranteed worst-case, the hash map's average-case performance better suits the workload pattern, which is read-heavy (approximately 80% lookups, 15% insertions, 5% deletions)."

Avoid These Common Mistakes

Mistake 1: Pasting your entire source code into the report Include key snippets. Put the full code in an appendix or submit it separately.

Mistake 2: Writing in first person excessively "I did this, then I did that, then I implemented this" gets repetitive. Mix in passive voice and focus on the design decisions rather than narrating your actions.

Mistake 3: Skipping the "why" Every significant design decision needs justification. "I used quicksort" is incomplete. "I used quicksort because its average-case O(n log n) performance and in-place sorting capability made it suitable for the memory-constrained environment specified in the requirements" is complete.

Mistake 4: Not discussing limitations Every implementation has trade-offs. Acknowledging them shows maturity and understanding. "The implementation does not handle concurrent access and would require mutex locks for thread-safety" is the kind of insight that earns extra points.

Mistake 5: Grammar and clarity Technical writing still needs to be well-written. Unclear sentences waste the reader's time and suggest you don't fully understand what you're describing.

---

Tools for CS Reports

Document Formatting

• LaTeX — The gold standard for CS academic writing (steep learning curve, excellent output)
• Overleaf — Online LaTeX editor with templates
• Google Docs/Word — Perfectly fine for most undergraduate assignments
• Markdown + Pandoc — Great if you want to write in plain text and convert to PDF

Diagrams

• draw.io — Free, browser-based diagramming
• Mermaid — Text-based diagram generation
• PlantUML — Text-to-diagram tool popular in CS
• Lucidchart — Professional diagramming (free tier available)

Code Formatting

• If using LaTeX: listings or minted packages
• If using Word/Docs: Use a monospace font and consistent formatting
• Many professors appreciate syntax-highlighted code screenshots

---

How Gradily Can Help

Writing about technical work requires a different set of skills than the technical work itself. Gradily can help you:

• Structure your report with clear sections and logical flow
• Explain algorithms and design decisions in clear academic language
• Write analysis sections that go beyond description
• Polish your technical writing for clarity and professionalism

Let Gradily help you communicate your CS work as effectively as you built it.

---

CS Report Checklist

• Title, name, course, and date
• Clear problem statement showing you understood the assignment
• Design decisions with justifications (the "why")
• Key code snippets with explanations (not the entire codebase)
• Testing methodology and results
• Performance analysis with data (tables, charts)
• Discussion of trade-offs and limitations
• Proper formatting (consistent fonts, headings, code formatting)
• Diagrams where they add clarity
• References for any external resources used
• Proofread for grammar and clarity

A great CS report tells the story of your solution: what problem you faced, how you thought about it, what you built, and how well it works. Master this skill, and you'll stand out in both academia and industry.