Refactor some classes to improve readability and maintainability

[ntung]

I used to look into the source code and intended to change some areas to make the codes more readable and maintainable. Is that worth?

For example:
When looking into the PR #282, I read the private method readXMLFromXMLEventReader spanning over 300 lines. It's actually hard to read and understand the logic implementation.

I can point out some other non-standards: code lines too long, some typos in Java docs, poor function docs, unused function arguments, a lot of uncomment codes, duplicated codes, redefined logger inside a method, etc.

If we agree this suggestion, I can contribute my time to work on these things gradually.

[draeger]

Thanks a lot for offering this, dear @ntung! I would definitely consider this worthwhile.

Improving readability and maintainability is valuable work, especially in a mature project like JSBML, where code has grown over many years and through many contributors. Refactoring overly long methods, improving documentation, fixing typos, removing dead code, or reducing duplication would certainly be appreciated.

Your example with readXMLFromXMLEventReader in #282 sounds very reasonable. Methods of that size can be difficult to review and maintain, so improving the structure there could be very helpful.

My only suggestion would be to separate purely structural cleanup from functional changes where possible. Readability improvements, formatting, Javadoc fixes, or the extraction of helper methods are usually straightforward to review. For larger refactorings that might affect behavior or public APIs, it would probably help to discuss the approach briefly in an issue or PR first, just to keep everyone aligned.

But overall, yes, I think such contributions would be very welcome, and many of these incremental improvements could make the codebase easier to work with over time.

[ntung]

Thank you for the warm response, @draeger! I'm happy to support the project and willing to make gradual contributions to improve the codebase over time.

I fully agree with your point on large refactorings — before making any massive structural changes that could affect behavior or public APIs, I will open a discussion first to make sure we're aligned. For smaller, purely cosmetic improvements (Javadoc, formatting, helper extraction, dead code removal), I'll go ahead and open PRs directly.

Looking forward to contributing!