3 ms·
I don't know much Rust (essentially none) but the sample doesn't seem to me to warrant the 'murkier' comment. It took me a few moments to realize that the loop
by kwhitefoot 7y ago
I don't know much Rust (essentially none) but the sample doesn't seem to me to warrant the 'murkier' comment. It took me a few moments to realize that the loop variable was not produced from
image1
but instead from
image1.raw_pixels().iter().zip(image2.raw_pixels().iter()
I would have created a local for that before the loop for clarity. And I would not have declared the ratio variable, that is surely unidiomatic as the last expression provides the result.
But apart from those stylistic quibbles it seems a model of clarity, the opposite of murky, whereas the Python version simply glues together opaque library calls.
- kevincox 7y agoAlternatively you can avoid the loop for the summing and just do. let diffsum: u64 = image1.raw_pixels().iter() .zip(image2.raw_pixels().iter()) .map(|(&p1, &p2)| u64::from(abs_diff(p1, p2))) .sum(); I find this a lot easier to read because there is no control flow in this snippet. I can see that it is just summing the diffs. I know some people prefer iterators and some prefer loops, however I think mixing them like was done often leads to less readable code.
- carlmr 7y agoI prefer iterators in concise places like this, but loops when there's a bit more logic inside.
- kevincox 7y agoDefinitely. If your logic flow naturally maps to common iterator methods I think it helps readability. If you need complex control flow it is best to use a loop then try to wrangle iterator methods to achieve it.