My Homemade Grammarly (est. Early 2025)
Inspiration
Sometime in my sophomore year, I was working on an essay and had my dad look over it, who then gave me a copy of the Economist’s Style Guide. The book is a collection of rules regarding various words the newspaper uses in its articles, with the purpose of laying out the structure for the best writing.
But the only reason I even opened up the book (besides being nice) was because I had just finished reading Orwell’s “Politics and the English Language”. The essay addressed the issue of lazy and redundant writing and how popular it has become, and it also came with a set of general rules for good writing.
These two books are what got me hooked on the idea of programming a document editor. So when my dad showed me a similar program he was making, I couldn’t pass up the chance to learn.
My .yml Files
My rules are just a collection of .yml files I made, but at first I had no idea how to structure one. So my dads program was my only model for how to do this kind of thing. Here is part of his too-wordy.yml file:
---
extends: substitution
message: "Consider '%s' instead of '%s'"
description: "Don't be too wordy"
level: warning
scope: text
ignorecase: true
swap:
- a little bit: “a bit” or “a little”
- a number of: some/many
- a variety of different things: a variety
- accomplish: do
- add together: add
- add up: add
- addressee: you
- advance forward: advance
- advance reservation: reservation
- after the conclusion of: after
- as well(?! as): too
- all of: all
The extends argument determines whether words should be removed or replaced. The message and description both explain what the .yml does in text. The level adds or removes severity from the popup next to the text bug. The scope and ignorecase tells the program where to look, and the swap (or token) argument list words for the program to look for.
Once I learned the syntax of yml and the essence of these arguments, I moved on to my own .yml files. Here is some of my cliches.yml file:
---
extends: existence
message: "'%s' is an overused cliche"
description: "Cliches can be fine, but you want to surprise the reader with your points, not use lame metaphors that everyone knows."
level: warning
scope: paragraph
ignorecase: true
nonword: true
tokens:
- Actions speak louder than words.
- All's fair in love and war.
- Bite the bullet.
- Break a leg.
- Don't count your chickens before they hatch.
- Don't cry over spilled milk.
- Easy as pie.
- Every cloud has a silver lining.
- Fool's gold.
- Good things come to those who wait.
- Haste makes waste.
- Hitch your wagon to a star.
- In the blink of an eye.
- It's a piece of cake.
- Jumping on the bandwagon.
- Kill two birds with one stone.
- Let the cat out of the bag.
- Like a bull in a china shop.
- Make hay while the sun shines.
- No pain, no gain.
- On the same page.
Now I have 14 such files I have created. You can see them on my Github page under the my_style folder.
At this point, I stopped. I don’t remember why, but life stops for nobody and I was probably just busy.
A few months later, however I went back into it, creating the program executed in the video above.
The Python Program
My program does 4 things: it gives my google account the right permissions, it copies the google document to my Documents folder, it replaces the google document with my edits, and then it can delete the folder at the end.
That first step was kind of a pain in the $&%, because google’s API website is a labyrinth only traversable through reddit forums and takes forever to load every new tab. But eventually I created all of the necessary secrets and keys, and that was good.
The second and third steps from there were easier, as I just needed to look at the google drive API documentation. There were some problems however, such as the fact that I lost a bunch of the formatting (fonts, indents, etc.) from google documents when copying over to a txt file.
These were just small hurdles though, and I finished my program within a couple of days.
Personally, I find the program itself to be a lot less interesting than the actual rules involved in it. Those are what I’ll be adding to in the future, not the code itself.
Conclusion: Why I Love This Project
After completing this program, I found myself thinking about ways I could make my document editor better.
The first fix I made was to change how the .yml files highlighted weak words in my text editor. This took a while, but I eventually made it look nice.
That’s a permanent fix however, and that’s not very satisfying. The whole appeal of this project is that I can just keep working on it by adding more and more rules, bringing my writing closer to perfection.
And now when I’m free, I can just go back and write more .yml files.
For example, a month or so back I used the book “Pathways to the Common Core” - a horrible book with extremely redundant wording - to think of more words I don’t want in my writing. I put all of those rules into book1.yml. It was very satisfying
Call me a nerd if you want (Liam L, passionate nerd)
and I plan to do it again. I’m thinking of downloading the Bible for a model of great writing, but every attempt has caused my computer to nearly crash.
So if you’re like me and find joy in the little quirks of programming, I highly recommend this project.