Don't use booleans?

Interesting thoughts on the use of Enums instead of Booleans:

Don’t use booleans

[quote=468280:@Wes Westhaver]Interesting thoughts on the use of Enums instead of Booleans:

Don’t use booleans[/quote]
Personally I would ignore almost all of the “advice” in that article.

this call would be more elegant or u need to live with quick info.
fetch(accountId,includeDisabled,includeHistory,includeDetails)

in visual basic it was possible to add the argument names
fetch accountId,includeDisabled:=false,includeHistory:=true,includeDetails:=true

sometimes are enums useful but i would split settings from a task / method
.includeHistory = True
.includeDetails = True
fetch(accountId)

Back in ye olden times, we used bitfield constants:

#define D_REOPEN (1<<0) /* Close and reopen when at end of device */ #define D_ISTAPE (1<<1) /* Device is a tape drive */ #define D_RAWTAPE (1<<2) /* Device is a raw magtape drive */ #define D_NOREWIND (1<<3) /* No automatic rewind on close of file */ #define D_ADVANCE (1<<4) /* Read/write always advances media */ #define D_NOREOPEN (1<<5) /* Explicit no reopen, D_REOPEN obsolete */ #define D_QFWRITE (1<<6) /* Query before first write to vol */ #define D_EJECT (1<<7) /* Eject media after use (Mac'sh machines) */ #define D_FORMAT (1<<8) /* Format the media if necessary */ #define D_SHMCOPY (1<<9) /* Cannot do I/O directly from shared memory */ #define D_RAWFLOPPY (1<<10) /* Device is a raw floppy drive */ #define D_IGNORECLOSE (1<<11) /* Ignore result of close on device */ #define D_REBLOCKS (1<<12) /* Device ignores I/O buffer size, reblocks */ #define D_NOAUTOSCAN (1<<13) /* Do not autoscan volume for errors */ #define D_OPENRW (1<<14) /* For writing, open in read/write mode */ #define D_LARGEFILE (1<<15) /* Can write more than 2GB (64-bit file size) */ #define D_SCSI (1<<16) /* Use SCSI IO module for communication */ #define D_ISFILE (1<<17) /* The destination is a file */

Similar concept so we could write:

if ( D_EJECT & D_RAWFLOPPY ) { /* deal with removable non-tape media */ }

But, it all boils down to coding style. In Xojo, I use both Booleans and Enums depending on the situation.

Care to share your reasoning? At first blush, the advice offered seems to improve code readability which is a good thing.

I think it makes readability worse. But YMMV.

alternate the OOP way

.fetch(accountId).includeHistory().includeDetails()

[quote=468452:@Tim Jones]Back in ye olden times, we used bitfield constants:
[/quote]
Who you calling old! Still use ‘em today. I love the principle of stacking a bunch of booleans into a single byte; now have you seen my spectacles, can’t read this ‘ere mobile smart telephone thing-a-me-gig.

[quote=468280:@Wes Westhaver]Interesting thoughts on the use of Enums instead of Booleans:

Don’t use booleans[/quote]

Best to ignore this, use a Boolean when appropriate.

I never use Booleans, and instead use Integer for two reasons:

  1. to get maximum portability and compatibility. Even if I store a True/False as 1/0, I can still return the result as:
If rs.Field("isItTrue").Boolean then …
  1. In case I ever need to add another choice eg -1 is for no choice yet made, deliberate non-choice (privacy issue) or correct answer is unknown

Yeah this is a powerful technique that still very much has its place.

[quote=468928:@Thom McGrath]Yeah this is a powerful technique that still very much has its place.
[/quote]
This dates back to when we had to write code to fit in low-KB of memory - every byte of your app counted. We still adhere to that small-is-better attitude and the “bru” binary is only 342KB:

-rwxr-xr-x 1 root root 342K Dec 23 14:02 bru

The use of “Magic Numbers” (ie: -1) is also discouraged by most programming texts. It might be possible that -1 may become a valid value at some time in the future development of your code. Better to use a dreaded Variant with IsNull or an object that provides properties to indicate if its value is undefined or unknown. Besides, Magic Numbers are non-obvious to the maintainers of the code.