for better readability, please split !open.isEmpty and let node = open.remove() into two lines.

I actually like this change. 😄 Having it all on one line would be my preference.

for better readability, please split node1 and node2 into two lines.

Again, no need to do this, plus in my opinion it doesn't actually improve readability.

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.

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).

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.

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.