Interesting thoughts on the use of Enums instead of 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, cant 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:
- 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
- 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.