Back to the main page.

Bug 1183 - boolean cfg options should need consistent values to be true or false

Status ASSIGNED
Reported 2011-11-23 16:52:00 +0100
Modified 2011-12-14 09:38:25 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: All
Operating System: All
Importance: P5 enhancement
Assigned to: Robert Oostenveld
URL:
Tags:
Depends on:
Blocks:
See also:

Jörn M. Horschig - 2011-11-23 16:52:55 +0100

As an example: ft_topoplotXXX requires cfg.highlight to be 'on' or 'off' In other functions, e.g. ft_plot_vector, the axis options can be 'yes' or 'no' My suggestion would be to make it completely equal and strict, e.g. stick to 'yes' or 'no', or make it completely flexible, e.g. allow 'yes', 'no', 'on', 'off' or even boolean true, false, 0, 1. I'd prefer the latter of course, because it allows for booleans, which is the standard in common programming languages when setting a flag


Jan-Mathijs Schoffelen - 2011-11-23 17:13:36 +0100

good point. Some functions also use istrue, which is either a private function or is defined within the function body. You may want to grep that to get an idea where it's used.


Boris Reuderink - 2011-11-28 14:35:55 +0100

Nice. Seems like a sensible thing to do. Defect by developer -> changed status to NEW.


Robert Oostenveld - 2011-11-29 10:40:18 +0100

the existing fieldtrip/utilities/istrue.m function allows for the full specification of yes/no/on/off/0/1/true/false and returns a boolean. Documentation wise sometimes makes more sense to represent it as yes/no, for example whether an option should be used in the algoirithm, or on/off when it pertains to plotting. The "logical" option for utilities/ft_checkopt could be extended to also support this.


Jan-Mathijs Schoffelen - 2011-12-07 14:03:55 +0100

try to be more consistent within the ft-functions. wherever possible, convert the things to booleans and evaluate those, rather than: if strcmp(..., 'yes') etc.