Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Improve code quality #43

Open
eprovst opened this issue Nov 11, 2020 · 0 comments
Open

Improve code quality #43

eprovst opened this issue Nov 11, 2020 · 0 comments

Comments

@eprovst
Copy link
Owner

eprovst commented Nov 11, 2020

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant