Auronas: remove force casts on dequeuing #969
Conversation
|
It's not really necessary to do this, since the |
| @@ -95,8 +95,7 @@ extension Huffman { | |||
| while queue.count > 1 { | |||
| // Find the two nodes with the smallest frequencies that do not have | |||
| // a parent node yet. | |||
| let node1 = queue.dequeue()! | |||
| let node2 = queue.dequeue()! | |||
| guard let node1 = queue.dequeue(), let node2 = queue.dequeue() else { return } | |||
There was a problem hiding this comment.
for better readability, please split node1 and node2 into two lines.
There was a problem hiding this comment.
Again, no need to do this, plus in my opinion it doesn't actually improve readability.
There was a problem hiding this comment.
It's not strictly needed, especially if you are not linting (where a force-unwrap rule would fail your build). I understand that this is not production code, but it's still good coding style to not force unwrap unless you are testing your code and, even then, you have XCTUnwrap.
There was a problem hiding this comment.
Force unwrap is perfectly acceptable when it cannot possibly fail. Writing code that handles errors that can never occur is more dangerous because it can hide subtle bugs or cause people to insert subtle bugs later (i.e. it adds complexity that doesn't need to be there).
There was a problem hiding this comment.
Not sure I follow the complexity argument in using guard statements. I take your point on force unwrap when it's impossible to fail, ergo my point above on tests. My point was good coding style - i.e., not getting in the habit of force unwrapping when you can easily guard. @snooky23 matter of taste, but I don't disagree with you.
There was a problem hiding this comment.
When the guard fails, you return from the method. This can never happen, but you've added logic that makes it seem like returning early from the method is allowed. But it isn't, since there is logic that happens after the while loop. Your change doesn't introduce a bug by itself because the return will never happen, but it makes it appear as if it's OK to exit from the method inside the while loop, which is not OK. Hence, you've added complexity that wasn't there before, and the potential for bugs to be introduced because the error handling path of your code is incorrect. It would be better to do a fatalError instead of a return, but that is also more complex than just force unwrapping.
| guard let node = open.remove() else { | ||
| break | ||
| } | ||
| while !open.isEmpty, let node = open.remove() { |
There was a problem hiding this comment.
for better readability, please split !open.isEmpty and let node = open.remove() into two lines.
There was a problem hiding this comment.
I actually like this change. 😄 Having it all on one line would be my preference.
Checklist
Description