Inspiration
While coding, one of the greatest struggles I've faced has always been debugging code: something will go wrong, and I'll puzzle over it for nearly an hour, only to find out there was a missing semicolon or typo that I had just barely missed. I wanted to create a tool that could help other people with this almost universally-recognized issue.
What it does
This tool identifies specific lines in code that could have grammatical error and isolates them so you can navigate to that section of your source code and fix it -- sadly, it's not automated yet!
How we built it
I incorporated elements of the inspect and AST modules, as well as the dir() command, into a class that would allow for proofreading of any Python open source code file to occur when it was instantiated as an object.
Challenges we ran into
The biggest one that still exists is the parsing of code: because every single individual line is evaluated rather than breaking commands down piecewise, often times there are issues with the way the line is perceived, especially it leaves room for a follow-up command at the end. This is currently extremely prevalent with indentation expectation issues after the initial line declaring a function or class. Another challenge is accessibility: currently users would have to download this program, then manually make commands or debug an issues that occur.
Accomplishments that we're proud of
This was a challenging project for me both because of the time constraint and because of the lack of knowledge I had of Python grammar, the specific modules used, and data structures. I am glad that I was able to learn much more about all of these fields, and then blend them in with something I did know.
What we learned
I learned much more about the three fields I mentioned above, and also about the different approaches in navigating nodes and what that would mean for anyone programming. While commands such as ast.walk() are more prevalently used, a downside is that they randomly navigate through nodes, which is disorderly and counterintuitive to the system I am trying to build, and it is also slower than a direct method. However, navigating through children nodes seemed to be unnecessary as well, especially when the focus is not conversion of every element of a command into a different language, but rather to focus whether or not it has the correct grammar to execute. With this focus in mind, I felt as though a simple approach was better.
What's next for Open Source Proofreader
Automation! Of course, fixing all of the challenges to make the current code better is the first priority, but improving it is nearly as essential. Being able to automate and then extend the process to language conversion would be a game changer.
Log in or sign up for Devpost to join the conversation.