There are two changes there. One, yes, is to catch s/==/=/ by making it an error (for Perl, that error is "Can't modify constant item in scalar assignment"). The other is to add braces. This is so that later it's easy to add another line that's within the branch. Otherwise, you might have this:
if ( 5 == foo )
call_function( foo );
call_other_function( foo );
...which actually means this:
if ( 5 == foo ) {
call_function( foo );
}
call_other_function( foo );
| [reply] [Watch: Dir/Any] [d/l] [select] |
That's exactly the reason. Many people do the same thing in Perl, too, considering we use the same assignment and equals operators.
Personally, I try to remember to do so during an initial version and I might make the swap if I'm already rewriting or refactoring code. I don't go through existing, working code looking for that and making the change. Changing something that's not in error is error prone in itself, and why take the time?
Update:
I completely missed the braces added at first. That's a good change, and it is another one I try to stick to in C and PHP (which have the same single-statement rule for conditionals) for initial versions. Still, unless I have some reason to change working code, I won't. When I change the code around that section, I'd probably go ahead and add the braces whether or not I was adding another statement. I wouldn't just go into the source and add the braces and not change anything else.
As an aside, the "blue" language (as opposed to the "Blue" language, apparently) has a single-expression rule for conditionals. All of its conditionals are done using the 'condition ? true : false' operators common to C and Perl, with the false case being purely optional. I'd say braces (or parentheses) are the way to go there, too, unless you're working with a very short single-line statement. | [reply] [Watch: Dir/Any] |