Is it really that bad to Use boolean parameters to make your functions do two things?

[yonojoy 2]

I use

FindFiles('c:\', RECURSIVE_YES);

with a bunch of predefined boolean constants.

Edited January 12, 2021 by yonojoy

[Mike Torrettinni 198]

22 minutes ago, yonojoy said:

I use

FindFiles('c:\', RECURSIVE_YES);

with a bunch of predefined boolean constants.

Interesting. I've been thinking about creating a global enum type, like TBooleanValues = (bEnableCotrol, bDisableControl, bRecursive, bNonRescursive,...) and use them as boolean True/False.

But this is still just an idea 😉 good to know somebody actually has implemented similar.

[David Heffernan 2293]

52 minutes ago, Mike Torrettinni said:

But this is still just an idea

A truly shockingly bad one at that!

[Mike Torrettinni 198]

Why do you say so? You don't think it's a good idea?

 

It would solve many many questions about using booleans; also it would be one common place where I can connect such methods. Will give it another thought, but it you have a suggestion please let me know.

Edited January 12, 2021 by Mike Torrettinni

[David Heffernan 2293]

53 minutes ago, Mike Torrettinni said:

Why do you say so? You don't think it's a good idea?

 

It would solve many many questions about using booleans; also it would be one common place where I can connect such methods. Will give it another thought, but it you have a suggestion please let me know.

You've had my suggestion. Use a boolean and give your function a good name. Where you can't do that, use an enumerated type.

 

You seem to be looking for problems where none exist. These kind of problems don't need to be fixed! 

[Mike Torrettinni 198]

2 minutes ago, David Heffernan said:

You've had my suggestion. Use a boolean and give your function a good name. Where you can't do that, use an enumerated type.

 

Thanks, I already improved some naming and split some methods so the name and what they do are more aligned and exact.

It's nice we have so many developers here and so many interesting implementations.

[David Heffernan 2293]

4 hours ago, Lars Fosdal said:

After doing a lot of SQL, I find myself wanting to name parameters in Delphi too...

TFileSearcher.FindFiles('c:\', aRecursive := True);

 

This is of course the holy grail, available in many other languages.

[mvanrijnen 121]

or use a const 🙂

 

const
  FILESEARCH_RECURSIVE = True;
  FILESEARCH_NONE_RECURSIVE = False;

...
...
TFileSearcher.FindFiles('c:\', FILESEARCH_RECURSIVE);

...
...

 

[edit]

already mentioned i see now, sorry

 

 

For myself i prefer the enumating way by the way.

 

Edited January 12, 2021 by mvanrijnen

[Mike Torrettinni 198]

2 minutes ago, mvanrijnen said:

or use a const 🙂

 

const
  FILESEARCH_RECURSIVE = True;
  FILESEARCH_NONE_RECURSIVE = True;

...
...
TFileSearcher.FindFiles('c:\', FILESEARCH_RECURSIVE);

...
...

 

[edit]

already mentioned i see now, sorry

 

It's OK, always good to know more developers using certain implementation. Just don't turn const -> enum or you might get a truly shocking jolt of electricity 😉

[Stefan Glienke 1901]

Always understand the reason behind guidelines, suggestions, principles: why is it a good thing to do x - not just because famous person y said so.

Because when you understand why something is a good or bad thing to do you are able to evaluate the situations where you want or dont want to follow them and what implications arise.

[David Heffernan 2293]

1 hour ago, mvanrijnen said:

or use a const 🙂

 

const
  FILESEARCH_RECURSIVE = True;
  FILESEARCH_NONE_RECURSIVE = False;

...
...
TFileSearcher.FindFiles('c:\', FILESEARCH_RECURSIVE);

...
...

 

[edit]

already mentioned i see now, sorry

 

 

For myself i prefer the enumating way by the way.

 

Probably another bad idea in this topic which seems to be collecting a huge number of bad ideas. Do this for do different unrelated functions, and now you can pass the consts intended for function1 to function2, and vice versa.

 

 

[Stano 139]

I have these basic rules
procedure name - verb. It expresses what the procedure does. He always has to do only one thing!
function name - noun. It expresses what it will actually return
names of routine argument - must express their purpose

It's nothing special if I rename something 5 times

[Guest]

tumb-rules:

1. if you works in a "team", follow the rules!
   1. the manager's project is your guide!
      1. if you make a mistake, it's his fault!  
      2. if he misses, it's his boss's fault!  
2. if not, follow your rules and FKY!!! 
   1. you should have already learned the basics in the environment in which you work!

Edited January 12, 2021 by Guest

[balabuev 97]

My viewpoint to the topic's initial question:

Whole WinAPI is written this way. I mean, almost every function provides flags parameter, which alters the function behavior. WinAPI also have examples of Enable/Disable like cases:

ShowWindow(wnd, SW_HIDE);
EnableWindow(wnd, FALSE);

I thingk, it's ok, and it's a kind of well known pattern.

 

 

[Mike Torrettinni 198]

3 hours ago, balabuev said:

EnableWindow(wnd, FALSE);

Good example. The syntax shows that boolean parameter actually controls to enable or disable window. Perhaps it would be better named EnableDisableWindow 😉

 

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enablewindow

Edited January 21, 2021 by Mike Torrettinni

[Lars Fosdal 1730]

EnableDisableWindow(wnd, FALSE) does not convey the meaning of FALSE, while EnableWindow(wnd, FALSE) does.

[balabuev 97]

Just now, Lars Fosdal said:

EnableDisableWindow(wnd, FALSE) does not convey the meaning of FALSE, while EnableWindow(wnd, FALSE) does.

Agree.

[Attila Kovacs 617]

EnableDisableWindow( Agree: boolean )

[Lars Fosdal 1730]

EnableDisableWindow(WhyNot: boolean)

[Mike Torrettinni 198]

8 minutes ago, Lars Fosdal said:

EnableDisableWindow(wnd, FALSE) does not convey the meaning of FALSE, while EnableWindow(wnd, FALSE) does.

Not really, or yes only when you read the documentation to know what false does. Same would be for DisableWindow(wnd, TRUE);

EnableDisableWindow name can give you more sense of what the function does, compared to the fact that EnableWindow can disable window.

 

Well in any case you need to read the documentation and then you know. I just wanted to point out that my original EnableDisableControls wasn't not such a bad name, after all 🙂

 

 

[Attila Kovacs 617]

SetWindow'sVisibleFlagTo( clChequered  );

[balabuev 97]

4 minutes ago, Mike Torrettinni said:

DisableWindow(wnd, TRUE);

DisableWindow with boolean parameter is a bad name, by the same reason why dontUseWidget is a bad name. As already described in this topic.

[Mike Torrettinni 198]

1 minute ago, balabuev said:

DisableWindow with boolean parameter is a bad name, by the same reason why dontUseWidget is a bad name. As already described in this topic.

I agree, although the point wasn't about the actual naming, but that boolean parameter does 2 opposite actions. The naming can be pretty much anything we want, I can use like EngedelyezoAblak() or AbilitaFinestra(), it would still be EnableWindow used to disable window.

 

 

[balabuev 97]

5 minutes ago, Mike Torrettinni said:

although the point wasn't about the actual naming, but that boolean parameter does 2 opposite actions

But, in this particualr case these two things are related. If the function name expresses a positive action and the boolean parameter also expresses a positive action - then it's a kind of acceptable style. Otherwise, it will be a mess:

procedure EnableWindow(AHandle: HWND; AEnable: Boolean);   // Good and consistent.
procedure EnableWindow(AHandle: HWND; ADisable: Boolean);  // Bad.
procedure DisableWindow(AHandle: HWND; AEnable: Boolean);  // Bad.
procedure DisableWindow(AHandle: HWND; ADisable: Boolean); // Bad.

 

[Mike Torrettinni 198]

1 minute ago, balabuev said:

But, in this particualr case these two things are related. If the function name expresses a positive action and the boolean parameter also expresses a positive action - then it's a kind of acceptable style. Otherwise, it will be a mess:

procedure EnableWindow(AHandle: HWND; AEnable: Boolean);   // Good and consistent.
procedure EnableWindow(AHandle: HWND; ADisable: Boolean);  // Bad.
procedure DisableWindow(AHandle: HWND; AEnable: Boolean);  // Bad.
procedure DisableWindow(AHandle: HWND; ADisable: Boolean); // Bad.

 

True,

 

Perhaps it would be better something like ControlWindow.Enable() or ControlWindow(wnd, cwEnable) or ControlWindow(wnd, [cwEnable, cwActive]) with type TControlWindow = (cwEnable, cwDisable, cwActive, csFocused...);