Skip to content
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

Fixes #33

Merged
merged 10 commits into from
Oct 13, 2023
Merged

Fixes #33

merged 10 commits into from
Oct 13, 2023

Conversation

chris-ha458
Copy link

Some of these deserve explanations :
c7c8f22

  • I apologize for the churn here. I changed this just a PR ago, but i forgot about this method. Reading the documentation for the method leads me to believe that this is the most correct approach. If I understand the code correctly, this library does not need any special line handling, just simple proper line handling that hopefully works cross platform. This seems to be exactly that.

2479d5f

  • This was how i debugged c7c8f22 for my platform, and it seems better to have an expect rather than a naked unwrap. As explained above, this part is just simple file handling of a file with a well known format so it seem like more complex error handling is unnecessary.

28974cb

  • when if blocks contain control statements like return break continue, else statements can often safely be removed.
  • Whether the match based version is clearer is unclear. However if it is not, an multiple if based version is included in the comments.
  • Feel free to lmk if you'd prefer the if based version.

Comment on lines 33 to 57
match (self.done, self.s.is_empty(), self.pending.is_empty()) {
(true, _, _) => None,
(_, true, _) => {
self.done = true;
Some("")
}
(_, _, false) => Some(std::mem::take(&mut self.pending)),
_ => {
for (i, b) in self.s.bytes().enumerate() {
if b == b' ' || self.splitters.contains(&b) {
let ret = &self.s[..i];
// dont include the space, but include everything else on the next step
if b != b' ' {
self.pending = &self.s[i..i + 1]
}
self.s = &self.s[i + 1..];
return Some(ret);
}
}
self.s = &self.s[i + 1..];
return Some(ret);
// trailing data
self.done = true;
Some(self.s)
}
}
// trailing data
self.done = true;
Some(self.s)
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced this is more readable than the existing code. Could you revert the change?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you prefer to else as well?
If i take them out the first part would look like this

        if self.done {
            return None;
        } 
        if self.s.is_empty() {
            self.done = true;
            return Some("");
        } 
...

The reason I ask is that if-else with returns in them triggers some lints.

Of course if you'd rather keep them in, regardless, I'll do that.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those sound like quite opinionated lints then. I'm usually fond of functional style, but this is a bit too much IMO.

@chris-ha458
Copy link
Author

reverted and removed unnecessary if's
468e4e2

@progval progval merged commit feaf9cd into progval:master Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants