-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
Refactor the entry point to make it more readable #1172
Refactor the entry point to make it more readable #1172
Conversation
Some applications move their 'global' data into a struct called `App` or `Application`. This makes it very clear what data belongs to the 'global' scope or in other words, to the application itself.
To have a clear distinction between code dealing with OS process characteristics and code of ncspot itself, it makes sense to move the async runtime together with ncspot as it doesn't have anything to do with the OS process.
Command line arguments are part of the OS process and should be under main.
Sometimes the use of an item wasn't clear without reading the code. This should help with that.
Application
This PR is just a suggestion with lots of small changes, in the hopes that it can make some of the code more readable. I don't mind if it is closed 🙂 As I don't want this to become a 1000 line diff, I'll mark this one as finished for now. There are some parts that I think could be adjusted further, but it would make this PR too big to review. I tried to clean up some parts of the code that I found a bit harder to read. I realize this isn't a 'do one thing' type of PR, as when I see something to improve, I can't help myself and try to improve it, leading to lots of different changes. If some smaller PRs are preferred, I'll happily split this one up.
Somehow the final stripped release binary also shrunk 300kb, which wasn't a goal, but is still a good thing I guess 😄 |
I really appreciate all the effort you put into this. I only had a brief look, but everything looks nice and manual testing didn't reveal any issues. I'd merge this now and if something comes up we can still fix it in tree. ❤️ |
Quite some Rust TUI applications move their 'global' data into a struct called
App
orApplication
. Other types of Rust (or non-Rust) applications might do this as well, I just checked TUI Rust applications. This makes it very clear what data belongs to the 'global' scope or in other words, to the application itself. For ncspot, this would be things like the queue, the library, the web API, probably the parsed configuration, Cursive and probably some other things. It makes themain.rs
file more readable and less scary looking for new contributors, and gives a nice overview of what ncspot consists out of from looking at theApplication
struct definition.Programs I checked were:
I forgot which ones used this pattern exactly, but most of them used it in one way or another.
This is just a suggestion, in an attempt to clean up the code around the entry point a bit. The bigger idea, which I don't know whether it is a good idea or not, is to make the ownership of items a bit more clear. Personally I find it hard to get a grasp of 'who owns what'. I wanted to attempt to make this a bit clearer, and this would be a first step. This PR won't be finished for a bit, but I wanted to make it already to hear whether this idea was maybe not a good direction to go, in which case I will close it 🙂