[Question] why double check connection?
2bndy5 opened this issue · comments
I've noticed that this lib does a double check for connection livelihood when needed. I was wondering what the intention is to check the connection again even after the first check would evaluate to true. On the CMake-4-Linux branch I've reduced
bool RF24Mesh::checkConnection()
{
if (getAddress(_nodeID) < 1) {
if (getAddress(_nodeID) < 1) {
return false;
}
}
return true;
}to
bool RF24Mesh::checkConnection()
{
return !(getAddress(_nodeID) < 1 && getAddress(_nodeID) < 1);
}as per the NASA C style guidelines (tests verify that it still works BTW).
If we change it to
return !(getAddress(_nodeID) < 1) || !(getAddress(_nodeID) < 1);I think the second check would only be evaluated if the first check fails. However, I may be mistaken in thinking C++ will actually ignore the rest of an || condition if the first operand is true.
Fact: lib owner wants to make dbl.check.
Original code is transparent and clear for me. Clearer then a boolen logic, when I try to find the difference in bool sides. But no difference.
So it is a codeformat habit.
So it is a codeformat habit.
Yeah, that's why I said "as per NASA C style guide". Direct quote from section 7.2.4.1:
Do not use nested if statements when only the if clause contains actions.
It goes on to show an example of inappropriate nested if statements that resembles the original code snippet in this issue's OP.
BTW there is a similar scenario in the RF24Mesh::requestAddress():
if (getNodeID(mesh_address) != _nodeID) {
if (getNodeID(mesh_address) != _nodeID) {
beginDefault();
return 0;
}
}which I reduced to
if (getNodeID(mesh_address) != _nodeID && getNodeID(mesh_address) != _nodeID) {
beginDefault();
return 0;
}on the CMake-4-Linux branch.
Maybe I didn't emphasize the question enough. I was wondering if there was some historic intention of doing a double check. Maybe a kind of signal integrity check?
getAddress sends a packet in some cases and waits for a reply, the second check is very likely there to just increase the amount of retries, so reliability.
ok I can see that. So, switching to an || condition wouldn't be feasible because getAddress() sends the MESH_ADDR_LOOKUP message to pipe 0 (& auto-ack is disabled for pipe 0 in RF24Mesh). Thus, this workaround for a manual retry. Thanks that clears up some confusion. 👍🏼
@Avamander BTW, the Nasa C style guide links in CONTRIBUTING.md files are currently broken. I'm guessing that NASA just did some kind of update to the NTRS site. Because the doc is so old, I was able to find a copy elsewhere on the web. I'll give them some time to hopefully complete the supposed site update, otherwise we may have to change the link in the CONTRIBUTING.md files.
BTW, the Nasa C style guide links in CONTRIBUTING.md files are currently broken.
They kinda like to move things around. I guess we could keep a copy if we find a nice copy. Or pick something similar but more easily accessible. It was initially picked because it was the closest one to what we had back then.
I've grown to like the practicality & flexibility in that guide. I found a copy http://www.grantronics.com.au/files/CStyleGuide.pdf
The && condition has to evaluate both operands. Furthermore, I've been testing with debug statements on, and I have been seeing 2 lookup types transmit and be received for both the scenarios I referenced.
that's what I thought it should do. I'll try using an || condition instead of && to see if that matches the originally desired behavior. If not I'll change it back to nested if statements.
turns out C++ does evaluate both operands of an || condition even when the first operand evaluates to true.
reverting back to nested if statements.