Suggestion: Refactoring `goto` Usage to Improve Maintainability

[ikpil]

Hello 👋

I would like to suggest a gradual refactoring of the goto usage in the ENet codebase to improve readability and maintainability.

Currently, the following goto labels are used throughout the code:

• goto commandError;
• goto useSendReliableCommand;
• goto nextPeer;
• goto discardCommand;
• goto notifyError;

While goto can be justified in certain low-level or performance-critical contexts, its presence generally leads to less structured control flow, making the code harder to read, maintain, and test.

Downsides of goto (as currently used)

Concern	Description
Reduced readability	Makes the control flow harder to follow, especially with deeply nested or long functions.
Harder to maintain	Developers need to trace multiple exit points and possible jumps, increasing cognitive load.
Testing complexity	Mid-function jumps obscure logical paths and edge cases.
Refactoring obstacles	Complicates efforts to modularize code or handle errors using structured techniques.
Departure from modern C practices	Contemporary C codebases generally prefer structured error handling using helper functions or control blocks.

I’d be happy to help by submitting small, incremental pull requests—starting with one goto case at a time (e.g., goto commandError;). Each change will aim to preserve behavior and minimize diff noise, while making the logic more idiomatic and maintainable.

Please let me know if this approach is acceptable, or if there are any guidelines or constraints I should be aware of when contributing.

Thank you for your time and for maintaining such a valuable networking library!

[zpl-zak]

Hey,

sounds like a good plan! I agree that we should aim to reduce the code complexity. Feel free to open incremental PRs as proposed, we will have to do some rigorous testing to ensure original functionality remains intact, however.

Thank you for looking into this!