Recent searches
Search options
I can't really figure out how to comment #Rust. I'm so used to so much happening in #Python one-liners that need a big paragraph length explanation above them.
With Rust I just wind up with rare little comments marking (to avoid future befuddlement) little tiny things happening and the function name and definition documents what the code does. Comments above functions are really just big markers so I can find where stuff starts.
"Who needs comments... can't you just read variable names?"
@stevenaleach The things I really need comments for (the comments that I forget to make) is when I redo something because it seems more logical / cleaner / faster but it turns out to be a bad idea. Because I have absolutely gone back and tried to do the same stupid thing again and then gone "Wait haven't I tried to change this before unsuccessfully?".
@drgroftehauge And I had a lot of checking step by step while building up functions printlns that I initially commented out and left in so I had what's going on commentary..... but I cleaned them out as each bit got finished.
Maybe leaving good "check what's happening here" printlns commented out *is* the best strategy actually and I should have left them all and made them really nice and explanatory.
The problem with commented code is that the compiler will not help to keep commented code up to date at the next code change.
So I delete commented code at commit time.
Using variable names to avoid comments is always preferable, but finding good variable names can be hard. And I see no way around that.
@KingmaYpe @drgroftehauge I'm happy that I built my project as a bunch of little services that work together so that I can swap them out with improved versions bit by bit.
I've decided not to enhance (just finalize) my current implementation (a multi-functional binary that takes on each role based on argv[1]), but to split each component off one at a time for enhancement and improved implementation.
I'm hoping to have decided on a good documentation convention by the time that begins.
That works well since I'm sure my existing code is *ugly*. I don't actually *think* in #Rust yet. Rust iterators and filters are still alien tools to me, so what I'm writing is really kinda a bastardized C with struct methods that follows ownership rules. A lot is, I'm sure, a lot longer and more dogmatic/pedantic than it should be if I were using the language properly.
Hopefully I'll be writing rustier Rust by the time I start component by component rewrites.
Once the code passes clippy it is a lot easier to maintain than any C.
The biggest #rustlang hurdle I had was using anyhow for error handling.
@KingmaYpe @drgroftehauge I'm not feeding this version to Clippy. We've not met and likely won't for a while yet. ;-).
I'm at the "got all the moving parts out of my head and doing their various movings on actual machines finally" phase, and just grateful to have gotten there.
I started learning #Rust probably five or six weeks ago for this project and I know my stuff isn't up to Clippy's criticism - or standards.
Clippy and anyhow are well known for good reasons. They will save maintenance time later on.
@KingmaYpe @drgroftehauge Yea, but I'm happy finalizing the behavior I want in the initial "reference" branch and then re-implementing all of its various "personalities" (services listening to various Unix sockets or TCP ports) individually from the ground up (again), with Clippy's aid and approval from the outset as a new "development" version/branch.
And each bit will be just itself and far easier to maintain. Or replace with alternatives at any time.