I know that ColdFusion is case insensitive by nature. It had never occurred to me though that conditional statements were also case insensitive. I am such a huge user of ListFind() and Compare(), both of which are case SENSITIVE, that I just started to assume that all conditionals were case sensitive. That's the reason why my custom tags end up looking like:
<cfswitch expression="#UCase( THISTAG.ExecutionMode )#"> <cfcase value="START"> <!--- ... ---> </cfcase> <cfcase value="END"> <!--- ... ---> </cfcase> </cfswitch>
I upper case the ExecutionMode variable because I am never sure what value it is going to be. Apparently though, as I just found out, that is entirely unnecessary. Switch statements, as well as all other simple conditional statements, are NOT case sensitive. To experiment a bit, I tried doing this:
<!--- Set a value with mixed case. ---> <cfset strValue = "Cool"> <!--- Check values without case sensitivity. ---> <cfswitch expression="#strValue#"> <!--- Check with same case. ---> <cfcase value="Cool"> It is Cool. </cfcase> <!--- Check with lower case. ---> <cfcase value="cool"> It is cool. </cfcase> </cfswitch>
Both cases above are the same word, but with different letter casing. Turns out, the above example throws an error:
Context validation error for tag CFCASE.
The CFSWITCH has a duplicate CFCASE for value "COOL".
ColdFusion is seeing the two "Cool" cases as having the same value. Then, just to double-check that I am not going completely crazy, I tested the case-insensitive check without duplicate values:
<!--- Check values without case sensitivity. ---> <cfswitch expression="#strValue#"> <!--- Check with a different case. ---> <cfcase value="COOL"> This is COOL </cfcase> <!--- Check with different value. ---> <cfcase value="LAME"> This is LAME </cfcase> </cfswitch>
This one does indeed access the first case statement value of COOL even though the original value was mixed-case.
I am not 100% sure how I feel about this. On one hand, I like that fact that I don't have to worry about cases in conditional statements. On the other hand though, I like the fact that ListFind() and Compare() are case sensitive and that I can leverage that in certain ways. I guess overall, it is going to create less bugs. And, now that I know it, I don't have to waste processing power changing the letter-casing of my switch statements.
Want to use code from this post? Check out the license.