this post was submitted on 24 Sep 2023
214 points (93.1% liked)
Programmer Humor
32568 readers
733 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Oh sorry, I misread what you typed and went on a tangent and just idly typed that in.
One thing you could do for your situation if you're planning on iterating over some array or vector of items is to use the inbuilt iterators and the chaining syntax. It could look like this
The collect also only collects results that are Ok(()) leaving you to match errors specifically within the map.
This chaining syntax also allows you to write code that transverses downwards as you perform each operation, rather than transversing to the right via indentation.
It's not perfect and sometimes it's felt a bit confusing to know exactly what's happening at each stage, particularly if you're trying to debug with something mid way through a chain, but it's prettier than having say 10 levels of nesting due to iterators, matching results, matching options, ect.
I definitely use that syntax whenever I can. One of the situations where I get stuck with the nested syntax that I shared is when the result of the function call in the for loop affects the inputs for that function call for the next item in the loop. Another is when I am using a heuristic to sort the iterator that I'm looping over such that most of the time I can break from the loop early, which is helpful if the function in the loop is heavy.
It feels like maybe this could be a code structure issue, but within your example what about something like this?
Does that kinda syntax work for your workflow? Maybe it'll require you to either pollute a single map (or similar) with a bunch of checks that you can use to trigger a break though.
Most of the time I've been able to find ways to re-write them in this syntax, but I also think that rusts borrowing system although fantastic for confidence in your code makes refactoring an absolute nightmare so often it's too much of a hassle to rewrite my code with a better syntax.
Thanks for this! I'll see if I can work something like this in.