Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Code quality improvement and codebase optimization #580

Open
BenCheung0422 opened this issue Nov 5, 2023 · 1 comment
Open

Code quality improvement and codebase optimization #580

BenCheung0422 opened this issue Nov 5, 2023 · 1 comment
Labels
Improvement Ideas for changes to features or content.

Comments

@BenCheung0422
Copy link
Member

BenCheung0422 commented Nov 5, 2023

For various reasons, the code quality should be improved, including formats, coding practices and error handlings. This includes making good use of standard libraries like Google Guava, Apache Commons, etc., reducing unnecessary blocks of codes and optimizing the codebase. The JavaDoc commenting style should also be united, an example can be taken from #579. Ideally, any potential errors and exceptions should be caught and handled properly, minimizing the chances getting unhandled errors, uninformative reports and unideal fallbacks/case handlings, thus making it cooperative with the upcoming crash report system (#461). This may need time to be come over.

@BenCheung0422 BenCheung0422 added Question A question that is useful to keep open in case people are experiencing problems. Improvement Ideas for changes to features or content. and removed Question A question that is useful to keep open in case people are experiencing problems. labels Nov 5, 2023
@Makkkkus
Copy link
Member

Makkkkus commented Dec 5, 2024

Over a year old. Has no comments.

I disagree that new libraries should be introduced to reduce "unneccecary blocks of codes and optimizing the database". New libraries usually add "unneccecary blocks of codes", as you usually have to compile and distribute the entire library when using it.

Ideally, any potential errors and exceptions should be caught and handled properly, minimizing the chances getting unhandled errors, uninformative reports and unideal fallbacks/case handlings

I also agree that there should be less errors in the project, but since this is so common sense, I don't think this needs to be said.

This does also not propose anything substantial and thus I think this should be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Ideas for changes to features or content.
Projects
None yet
Development

No branches or pull requests

2 participants