- Wed Aug 12, 2015 5:27 am
#25770
It's bad because you have to read the inside of the if block {} to determine that it is a test for failure.
The implicitly leads to confusion for readers and for debugging.
I prefer the readability way:
Also, relying on True = 1 and False = 0 may cost you a ton of time debugging. An example that the standard libc API 'strcmp(const char*, const char*)' returns 0 when two input strings are identical and not-0 otherwise. I've seen many people face this simple but deadly bug
kenn wrote:datltq wrote:We call a method called 'connect' of the instance 'client'.
client.connect(host, httpPort) will return a value, if it is ZERO - indicate that it is failed by the one who programmed it, code in the block will run.
Bad code practice though, IMO
Just curious; why is the above a bad practice? It's common in alot of languages for a function to return true on success, false on failure.
It's bad because you have to read the inside of the if block {} to determine that it is a test for failure.
The implicitly leads to confusion for readers and for debugging.
I prefer the readability way:
Code: Select all
if (client.connect(host, httpPort) == CONNECT_ERROR)
{
/* ERROR */
}
It's common in alot of languages for a function to return true on success, false on failure.
Also, relying on True = 1 and False = 0 may cost you a ton of time debugging. An example that the standard libc API 'strcmp(const char*, const char*)' returns 0 when two input strings are identical and not-0 otherwise. I've seen many people face this simple but deadly bug
