View Source

Empty strings should not be used within calculations. A blank custom function named "Null" should be created and used for empty values (*see note below)
^{Within solution code this increases code readability and distinguishes literal values and escaped text from empty values.}

Case (
	If ( PatternCount ( Table::fieldName ; Tab & Tab ) ≥ 1;
		"Awesome use of indentation!";
		Null
		);
	If ( PatternCount ( Table::fieldName ; Tab ) ≥ 1 ;
		"Good code should be easy to read";
		Null
		);
	Null
)
// Note the above function uses another custom function
// which simply returns a tab character in order to improve
// readability

good

Case (
	If ( PatternCount ( Table::fieldName ; "	" & "	" ) ≥ 1;
		"Awesome use of indentation!";
		""
		);
	If ( PatternCount ( Table::fieldName ; "	" ) ≥ 1 ;
		"Good code should be easy to read";
		""
		);
	""
)

bad

Here's a series of test cases for clarification - the subtle differences in FM between Null, reserved word False and "" (literal empty string):

Expression	Result	Notes
Null		Result is empty.
GetAsBoolean ( Null )	0	GetAsBoolean returns 0/1 for expression results.
not Null	1	The boolean inverse of Null, or 1.
Null = 0	0	False: This is boolean false because FM does not evaluate empty to reserved word False (0).
GetAsBoolean ( Null ) = 0	1	True: The explicit FM boolean interpretation of Null is 0.
GetAsBoolean ( Null ) = False	1	True: A different adaptation - FM reserved words True and False are evaluated to the boolean 0/1 values, so 0 = 0.
Null = False	0	False: This is the most interesting case of all. Null is technically empty and False evaluates to boolean 0, so they are not equal.
Null = ""	1	True: The literal empty string "" evaluates the same in FM as the empty return of Null.,

Code within a custom function can and should use double quotes for empty values "". This decreases custom function dependencies on the "null" function - making them more portable for copy-pasting.