As anyone who has skimmed through the code will attest: the code is a mess and so is the repo. I started this project three years back, the summer before uni, it shows...
To clarify, it's not rubish. The parser, the most important part, is backed by tests so although it's messy that part is pretty stable.
At the interface between the parser and other modules things are okay. The ast is a good representation. Adding some utility functions there might reduce some complexity elsewhere, though.
That's a general problem, a lot of functionality is duplicated or concentrated in enormous functions. A lot of refactoring will be needed and even more software design (in the extend Go allows for it).
When functions are smaller it'll also be easier to add tests, which make bugs easier to catch and the software easier to maintain, as we can detect regressions. Adding tests for closed bugs (starting with historic ones) for instance is a good start.
In general I think it's best to first start cleanup at the repo level, figuring out which files belong where. This should be done as soon as possible to prevent future packaging headaches. Fixing the CI is also a minor point of action that can happen at this point.
Afterwards the focus is code. The interface between the cli and the export modules should be looked at first as it's currently one of the biggest messes in the program, if needed by adding temporary functions that abstract away the old uglyness. When that is done, a little bit of polishing can be done to the ast to prepare for the next step. Which is reworking the export modules, as these are the main places where features are added. The cli should get some love after that but probably has already mostly been alright after the first step. Finally it's time to basically throw out the old parser and rework it from scratch as the current design frankly allows for no code reuse whatsoever at that time the languages module can also receive some minor improvements.
In the meantime it's probably pretty safe to hack some features into the export modules. When possible by already partially refactoring the module, of course.
This is a lot of work with little visible external effect, but it's necessary for the health of the project and will greatly improve the ability to add feature in the future.
As anyone who has skimmed through the code will attest: the code is a mess and so is the repo. I started this project three years back, the summer before uni, it shows...
To clarify, it's not rubish. The parser, the most important part, is backed by tests so although it's messy that part is pretty stable.
At the interface between the parser and other modules things are okay. The ast is a good representation. Adding some utility functions there might reduce some complexity elsewhere, though.
That's a general problem, a lot of functionality is duplicated or concentrated in enormous functions. A lot of refactoring will be needed and even more software design (in the extend Go allows for it).
When functions are smaller it'll also be easier to add tests, which make bugs easier to catch and the software easier to maintain, as we can detect regressions. Adding tests for closed bugs (starting with historic ones) for instance is a good start.
In general I think it's best to first start cleanup at the repo level, figuring out which files belong where. This should be done as soon as possible to prevent future packaging headaches. Fixing the CI is also a minor point of action that can happen at this point.
Afterwards the focus is code. The interface between the cli and the export modules should be looked at first as it's currently one of the biggest messes in the program, if needed by adding temporary functions that abstract away the old uglyness. When that is done, a little bit of polishing can be done to the ast to prepare for the next step. Which is reworking the export modules, as these are the main places where features are added. The cli should get some love after that but probably has already mostly been alright after the first step. Finally it's time to basically throw out the old parser and rework it from scratch as the current design frankly allows for no code reuse whatsoever at that time the languages module can also receive some minor improvements.
In the meantime it's probably pretty safe to hack some features into the export modules. When possible by already partially refactoring the module, of course.
This is a lot of work with little visible external effect, but it's necessary for the health of the project and will greatly improve the ability to add feature in the future.