bytestring-net / bevy_lunex

Blazingly fast path based retained layout engine for Bevy entities, built around vanilla Bevy ECS.
https://bytestring-net.github.io/bevy_lunex/
Apache License 2.0
478 stars 18 forks source link

Split up large files into smaller modules #56

Closed badcodecat closed 3 weeks ago

badcodecat commented 3 weeks ago

Proposal

While looking through the codebase, I noticed that there are quite a few large files (a thousand lines or more). I propose splitting these files into smaller modules to make the codebase more readable, maintainable, and easier to navigate for newcomers (like me in this case!).

Example

As an example, layout.rs in lunex_engine defines the Layout enum, but it also defines Boundary, Window, Solid, and Div structs for use in the Layout enum. In this case, I think it would be beneficial to move the layout modes (Boundary, Window, Solid, and Div) into their own files, either in the same directory or in a subdirectory.

Here's how the file structure could look after moving the layout modes into a subdirectory:

πŸ“ layout
β”œβ”€ πŸ“œ layout.rs
└─ πŸ“ layout_modes
    β”œβ”€ πŸ“œ boundary.rs
    β”œβ”€ πŸ“œ window.rs
    β”œβ”€ πŸ“œ solid.rs
    └─ πŸ“œ div.rs

Here is a sample of the corresponding change in layout.rs:

mod layout_modes;

pub enum Layout {
    layout_modes::boundary::Boundary,
    layout_modes::window::Window,
    layout_modes::solid::Solid,
    layout_modes::div::Div,
}

impl Layout {
    ...
}

...

Considerations

Of course this is just an aesthetic change, the proposal doesn't offer any technical improvements. If this is a change that you would like to see, I would be happy to try and implement it (to the best of my ability, erring on the side of caution as I am not familiar with the codebase).

IDEDARY commented 3 weeks ago

Reason

While some cleanup would come in handy to the library, I feel like this change is more related to personal taste. I like to couple related code together and not split them across different files. I feel like having multiple tabs open and jumping between them decreases efficiency and increases mental overhead. That's why I split files based on abstraction and not struct hierarchy. Of course, this is very subjective.

For now

When we add new stuff and the file gets too large, we can split it. But now I don't really think its worth the effort. It is not necessary.