Skip to main content
Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.

Switch Statements Not Case Sensitive

By Ben Nadel on
Tags: ColdFusion

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.


Reader Comments