How I Wrote a Python Script to Roast My Own Code

Roasting your own code isn’t just brutal — it’s brilliant.

How I Wrote a Python Script to Roast My Own Code

Let’s be honest: we’ve all written code that deserves to be publicly shamed.
Messy functions. Useless comments. Abominations like temp2_final_final.py.

After yet another late-night commit that looked more like a ransom note than clean Python, I had a wild idea:

What if I wrote a Python script that could roast my code for me?
Not just lint it or refactor it — but insult it. Clown on it. Serve me hard truths with zero sugar-coating.

So I did.

And the surprising part?
It made me a much better developer.

In this article, I’ll walk you through why I built this weird little tool, how it works, and how it helped me level up my code quality — and my sense of humor.

Why I Wanted to Roast Myself with Python

Code reviews are great. But they usually come with either too much diplomacy or not enough time.
Linters and static analyzers are helpful — but they’re cold, factual, and limited to syntax and style rules.

What I needed was something between a snarky senior dev and a brutally honest stand-up comic.
Something that could point out the dumb stuff I keep doing… but in a way that made me want to fix it.

So instead of waiting for judgment from a code reviewer, I decided to pre-judge myself — with a script that made me laugh and learn.

What the Script Actually Does

I called it code_roaster.py, and here’s what it does:

• Parses your Python files
• Looks for common “bad code smells”
• Generates witty (and mildly offensive) roast lines
• Outputs a list of mock insults, tied to specific lines in your code

Think of it as a one-person roast session, hosted by your own machine.

Some of the roasts it dishes out:

• Found a variable named data → “Wow. ‘data’? Did your creativity time out?”
• Found a function longer than 50 lines → “Did you forget functions are not novels?”
• Too many nested if statements → “Nice pyramid. Is this code or a tomb for maintainability?”
• Too many TODO comments → “TODO: Clean this up. Just like you said. Three months ago.”

It even roasts itself occasionally:

print("Running code roaster... If this script crashes, just consider it meta.")

How I Built It (Step-by-Step)

Let’s break down the core parts of the roaster.

1. Parsing the Python File

I used Python’s built-in ast module to parse code safely:

import ast 
 
def parse_code(file_path): 
    with open(file_path, 'r') as f: 
        tree = ast.parse(f.read()) 
    return tree

This gave me access to the structure of the code — functions, classes, variable names, and more.

2. Finding Code Smells

I created a list of bad patterns to look for:

• Functions over X lines
• Generic variable names like data, temp, foo
• Too many TODOs
• Nested control flows
• Empty exception blocks

Each one triggered a custom roast message.

Example logic:

def check_function_length(node): 
    if isinstance(node, ast.FunctionDef): 
        start = node.lineno 
        end = max(getattr(n, 'lineno', start) for n in ast.walk(node)) 
        if (end - start) > 50: 
            return f"Function '{node.name}' is {end - start} lines long. Planning a sequel?"

3. Generating the Roasts

I stored roast templates and used them dynamically:

roasts = { 
    'long_function': [ 
        "Function '{name}' is {lines} lines long. Planning a sequel?", 
        "'{name}' called. It wants to be broken into smaller functions." 
    ], 
    'todo_overload': [ 
        "Another TODO? When exactly *do* you plan to do these?", 
        "Your TODOs have TODOs." 
    ] 
}

Then used Python’s random.choice() to mix things up so every roast felt fresh.

4. Outputting the Insults

The final output was a list of targeted roasts with line numbers:

🔥 Line 84: Found function 'process_all_user_data' with 76 lines. Are you trying to win a Pulitzer? 
💀 Line 12: Variable named 'temp'. Truly groundbreaking. 
😂 Line 132: TODO found. Again. Still unfixed. Shocking.

You could even run it as a pre-commit hook, if you’re bold enough.

What I Learned From Being Roasted

Here’s the unexpected part: the more I ran it, the more I started preemptively avoiding bad code.

Some takeaways:

• Naming matters. Seeing my generic names mocked made me reach for clearer, more specific ones.
• Function size is a real red flag. Anything over ~40 lines almost always benefitted from being split.
• Don’t let TODOs rot. My script shamed me into either doing the task or deleting the note.
• Code should be readable, even under ridicule. If my own script struggled to parse it, that’s a problem.

It was like pair programming… with a mean but helpful friend.

Final Thoughts

Writing good code is hard.
But getting better doesn’t always have to be dry, serious, or strictly academic.

Sometimes, the best way to improve is to roast yourself.
Shine a harsh (but hilarious) light on your bad habits — and fix them with a smirk.

Because if you can’t laugh at your code… someone else will.