Alright folks, gather ’round, let me tell you about this little escapade I had. The title? Yeah, it’s a bit dramatic: “i am your reckoner mortals”. Sounded cool, so I went with it. Basically, I wanted to build something that… well, judges. Judges code, finds flaws, the whole shebang.
Phase 1: The Spark
It all started with me getting annoyed by some really bad code I stumbled upon. I mean, REALLY bad. Spaghetti code that looked like it was written by a caffeinated monkey. So, I thought, “Hey, why not automate this misery?” I envisioned a tool that could sniff out common code smells, potential security vulnerabilities, and just plain ol’ bad practices.
Phase 2: Getting My Hands Dirty
First things first, I needed a language. Python seemed like the obvious choice. Easy to read (mostly), lots of libraries, and I kinda knew my way around it. So, I fired up my trusty VS Code and started sketching out the basic structure.
I started by defining the core functionality. What kind of things would this “reckoner” be looking for? I listed down things like:
Code Duplication: Nobody likes copy-pasting code.
Long Methods: Monsters that are hard to understand and maintain.
Complex Conditionals: Nested if-else statements that make your brain hurt.
Unused Variables: Waste of space, cluttering up the code.
Phase 3: Diving into the Code
This is where things got interesting. I started digging into Python’s ast (Abstract Syntax Trees) module. It’s basically a way to represent code as a tree-like structure, making it easier to analyze. It was a bit of a learning curve, but once I got the hang of it, I could traverse the code, find specific patterns, and identify potential issues.
For example, to detect long methods, I did something like this:
import ast
class MethodVisitor(*):
def __init__(self):
*_methods = []
def visit_FunctionDef(self, node):
if len(*) > 50: # Arbitrary threshold
*_visit(node)
def find_long_methods(filename):
with open(filename, 'r') as f:
tree = *(*())
visitor = MethodVisitor()
*(tree)
return *_methods
This little snippet walks through the code, finds all the function definitions, and checks if their body has more than 50 lines. If it does, boom, it’s flagged as a long method.
Phase 4: More Features, More Problems
I kept adding more and more checks. Detecting code duplication involved hashing code blocks and comparing them. Complex conditionals required traversing the AST and counting the nesting levels of if statements. It was a lot of trial and error, and a lot of Googling.
One of the biggest challenges was balancing accuracy with performance. I didn’t want the “reckoner” to take forever to analyze a single file. So, I had to be smart about how I traversed the AST and how I performed the checks.
Phase 5: The Reckoning (First Version)
After a few weeks of hacking, I had a working (ish) version. It could analyze Python code, identify various code smells, and generate a report. It wasn’t perfect, but it was a start.
I ran it on some of my older projects, and boy, did it find some things. I was both embarrassed and strangely satisfied. It felt good to have a tool that could point out my own mistakes.
What I Learned
This project taught me a ton about code analysis, ASTs, and the importance of writing clean, maintainable code. It also reinforced the idea that there’s always room for improvement, even in your own code.
Future Plans
I’m planning to keep working on this “reckoner.” I want to add support for more languages, improve the accuracy of the checks, and maybe even integrate it with a CI/CD pipeline. Who knows, maybe one day it’ll be a full-fledged code quality tool. But for now, it’s just a fun side project that helps me write better code (hopefully).
So yeah, that’s the story of my “i am your reckoner mortals” project. A bit ambitious, a bit silly, but a whole lot of fun. Hope you enjoyed the journey!
