- Any results or Boolean settings in calculations are written using FileMaker's support for True and False (not as literal string values such as 'True' and 'False') instead of using the values of zero (0) and (1). This increases readability of code.
|
good |
|
bad |
10 Comments
Anonymous
One disclaimer on this convention is that you need to be sure that your boolean value is being passed literally and not as a string.
Local and global variables seem to know the difference (storing the value as 1), but you might be surprised with a string that evaluates to False if you pass it through other functions or calculations without care.
Donovan Chandler
Beezwax Datatools, Inc.
Anonymous
How about adding and promoting the use of xor as the toggle as it works with either 01 or truefalse
(anyBooleanResult) xor True
john renfrew
Matt Petrowsky
I'd say that XOR is a really hard concept for many to grasp. If you'd like to submit it as a proposal for best practices then please do!
For the curious...
Note: the only xor that equals True is True xor False
Matt Navarre
While I like the idea of using 'True' and 'False' instead of 0 and 1, I've never seen this in the wild more than a couple times in 20+ years of FileMaker work. Given that, I'm not sure it merits becoming the standard. I don't think 0 and 1 are particularly difficult constructs.
Matt Petrowsky
I think you may be misreading the spec. FileMaker has support for True and False which are then converted internally to their Boolean equivalent of 1 and 0. Their storage is numeric. It's simply syntactic difference.
Matt Navarre
There's another important issue related to Boolean values in FileMaker - and that's how they are stored as fields.
First, a boolean should be a number field, and not text.This uses much less space in the file, by about 50% just based on the field type. Also, in really huge record sets or deeply relational searches, will be a bit faster.
Second, I have found that it's better just to store 1, and not to write zero values. This also reduces the size and especially increases the relationship performance on this field.
Third, Boolean true values should be stored for the smaller record set. For example, if you have 1000 records, and 200 of them are vendors, then the the IsVendor field would be populated with 1, and the other 800 records would be null.
Fourth, Boolean fields might be titled IsTrue or IsVendor or NotMailingList to make clear that they are boolean, and what a true value means.
Matt Petrowsky
With regards to the above standard, the only argument you're making here is to not use a zero (0) and opt for Null vs. 1.
I don't think this is something that should be considered a standard as I'm sure there are many developers who feel that storing a zero vs. Null is just fine.
Suggestions such as using Null vs. zero(0) and specific naming of types of fields can be added into Best Practices. You can make the Proposals by adding a page in that section.
Arnold Kegebein
I am open for both ways using Null or zero. But consider that FileMaker's checkbox, will insert/remove the entry. With a simple checkbox this will be 1 and null, not 1 (True) and 0 (False).
Jeremy Bante
I've seen some developers treat 0 and Null values in almost-boolean fields differently, where 0 represents an explicit False value, whereas Null represents "n/a". They both correctly get treated as False when needed, but there is a useful difference.
Anonymous
0, 1, and null please. Matt Navare's comment on field naming of IsTrue or NotTrue is spot on.