Return to Answer

Here are some serious concerns why assignment inside conditions is bad:

1. The classic == versus = newbie bug. Instead of adopting an obfuscated coding style to prevent this bug, ie if(NULL == var), simply avoid assignment inside conditions.

2. Assignment inside conditions makes it harder for a compiler or static analyser to find actual bugs in your code.

3. Order of evaluation issues. For most operators in C/C++, the order of evaluation is implementation-defined behavior. This means that you cannot know whether the left side or the right side of the = is evaluated first, which may or may not lead to fatal bugs. A typical example of a possibly fatal bug is x=y=0;, which the compiler is free to interpret as "put uninitialized garbage in x, then put 0 in y". Bugs like this are more likely to occur inside conditions.

4. Undefined behavior issues. This is related to the order of evaluation issue above, but even more severe. It occurs when you write code like while(arr[i] < i++). This is undefined behavior and your program is free to crash & burn if your code contains it. http://stackoverflow.com/search?q=i%2B%2B+undefined+behavior

Reason 1 and 2 above are taken from the widely-recogniced industry standard MISRA-C:2004, which bans assignment inside conditions in rule 13.1. Assignment inside conditions is also banned by CERT C, EXP18-C.

Here are some serious concerns why assignment inside conditions is bad:

1. The classic == versus = newbie bug. Instead of adopting an obfuscated coding style to prevent this bug, ie if(NULL == var), simply avoid assignment inside conditions.

2. Assignment inside conditions makes it harder for a compiler or static analyser to find actual bugs in your code.

3. Order of evaluation issues. For most operators in C/C++, the order of evaluation is implementation-defined behavior. This means that you cannot know whether the left side or the right side of the = is evaluated first, which may or may not lead to fatal bugs. A typical example of a possibly fatal bug is x=y=0;, which the compiler is free to interpret as "put uninitialized garbage in x, then put 0 in y". Bugs like this are more likely to occur inside conditions.

4. Undefined behavior issues. This is related to the order of evaluation issue above, but even more severe. It occurs when you write code like while(arr[i] < i++). This is undefined behavior and your program is free to crash & burn if your code contains it. https://stackoverflow.com/search?q=i%2B%2B+undefined+behavior

Reason 1 and 2 above are taken from the widely-recogniced industry standard MISRA-C:2004, which bans assignment inside conditions in rule 13.1. Assignment inside conditions is also banned by CERT C, EXP18-C.

Here are some serious concerns why assignment inside conditions is bad:

1. The classic == versus = newbie bug. Instead of adopting an obfuscated coding style to prevent this bug, ie if(NULL == var), simply avoid assignment inside conditions.

2. Assignment inside conditions makes it harder for a compiler or static analyser to find actual bugs in your code.

3. Order of evaluation issues. For most operators in C/C++, the order of evaluation is implementation-defined behavior. This means that you cannot know whether the left side or the right side of the = is evaluated first, which may or may not lead to fatal bugs. A typical example of a possibly fatal bug is x=y=0;, which the compiler is free to interpret as "put uninitialized garbage in x, then put 0 in y". Bugs like this are more likely to occur inside conditions.

4. Undefined behavior issues. This is related to the order of evaluation issue above, but even more severe. It occurs when you write code like while(arr[i] < i++). This is undefined behavior and your program is free to crash & burn if your code contains it. http://stackoverflow.com/search?q=i%2B%2B+undefined+behavior

Reason 1 and 2 above are taken from the widely-recogniced industry standard MISRA-C:2004, which bans assignment inside conditions in rule 13.1. Assignment inside conditions is also banned by CERT C, EXP18-C.

Here are some serious concerns why assignment inside conditions is bad:

1. The classic == versus = newbie bug. Instead of adopting an obfuscated coding style to prevent this bug, ie if(NULL == var), simply avoid assignment inside conditions.

2. Assignment inside conditions makes it harder for a compiler or static analyser to find actual bugs in your code.

3. Order of evaluation issues. For most operators in C/C++, the order of evaluation is implementation-defined behavior. This means that you cannot know whether the left side or the right side of the = is evaluated first, which may or may not lead to fatal bugs. A typical example of a possibly fatal bug is x=y=0;, which the compiler is free to interpret as "put uninitialized garbage in x, then put 0 in y". Bugs like this are more likely to occur inside conditions.

4. Undefined behavior issues. This is related to the order of evaluation issue above, but even more severe. It occurs when you write code like while(arr[i] < i++). This is undefined behavior and your program is free to crash & burn if your code contains it. http://stackoverflow.com/search?q=i%2B%2B+undefined+behavior

Reason 1 and 2 above are taken from the widely-recogniced industry standard MISRA-C:2004, which bans assignment inside conditions in rule 13.1. Assignment inside conditions is also banned by CERT C, EXP18-C.