== Why is this an issue?

``++bool++`` is often used to implement an ``++enum++`` with two values. But when used carelessly, this leads to error-prone code. While it may seem reasonable when defining a boolean function parameter, the meaning might not be so clear at the function call point. 


If the function only has a single boolean argument, the potential ambiguity is mitigated: the function name can indicate its purpose, and what ``++true++`` and ``++false++`` mean. But when a function has more than one boolean argument, it becomes increasingly difficult to come up with  descriptive names. Moreover, it becomes very easy for callers to inadvertently swap the argument order. In such cases, it is much clearer to use an explicit ``++enum++`` or, if the boolean has a logical relation to  another argument, to package them together in a ``++struct++``, where the data member name can give meaning to the boolean. Another option is to split dealing with the multiple boolean arguments into multiple functions because sometimes multiple boolean parameters indicate a function that's trying to do too much.


=== Noncompliant code example

[source,cpp]
----
class Image;

Image* loadImage(const char *path, bool bw, bool lowRes, bool createEmptyIfNotExist); // Noncompliant
bool saveImage(const Image *image, const char *path, bool color, bool highRes);  // Noncompliant

void f(const char* path) {
  Image *image = loadImage(path, false, true, false);
  // do some processing on image
  saveImage(image, path, true, false);
}
----


=== Compliant solution

[source,cpp]
----
class Image;
enum class ColorMode {RGB, BlackAndWhite};
enum class Resolution {Full, Low};
enum class NotExistFallback {CreateEmpty, ReturnNullPtr};

Image* loadImage(const char *path, ColorMode mode, Resolution res, NotExistFallback fallback);
bool saveImage(const Image *image, const char *path, ColorMode mode, Resolution res);

void f(const char* path) {
  Image *image = loadImage(path, ColorMode::RGB, Resolution::Low, NotExistFallback::ReturnNullPtr);
  // do some processing on image
  saveImage(image, path, ColorMode::RGB, Resolution::Low);
}
----


ifdef::env-github,rspecator-view[]
'''
== Comments And Links
(visible only on this page)

=== on 2 Sep 2019, 19:37:20 Loïc Joly wrote:
\[~geoffray.adde] Can you please review my changes?

=== on 9 Sep 2019, 20:09:11 Ann Campbell wrote:
\[~geoffray.adde], [~loic.joly] this description starts, essentially with "boolean arguments confusing / bad" and then moves on to "1 boolean arg okay 2+ bad". Which leaves me wondering what happened to boolean arguments being bad? I think some additional content/wordsmithing is needed here.

=== on 10 Sep 2019, 09:30:51 Loïc Joly wrote:
\[~ann.campbell.2]The plan was the following:

* bool can be confusing
* 1 argument : We have ways to deal with the confusion
* More than one : Those ways no longer work

Do you find this plan more reasonable, and if yes, what can we do t make it more explicit?



=== on 10 Sep 2019, 13:17:42 Ann Campbell wrote:
\[~loic.joly] I do find that more reasonable. 


The middle bullet, is what I find missing in the current version. Maybe just add it in? :)

=== on 10 Sep 2019, 14:25:05 Loïc Joly wrote:
This sentence was supposed to be the middle bullet...


> If the function only has a single boolean argument, the function name can indicate its purpose, and what true and false mean

=== on 10 Sep 2019, 14:59:28 Ann Campbell wrote:
\[~loic.joly] it's too weak after the strength of the first paragraph. We need a balance between the two.

=== on 10 Sep 2019, 16:01:18 Loïc Joly wrote:
\[~ann.campbell.2] Are the strength/weaknesses better balanced now?

=== on 10 Sep 2019, 18:47:28 Ann Campbell wrote:
Much better balance [~loic.joly]. I've done a little wordsmithing. See if you approve. 

=== on 10 Sep 2019, 19:57:22 Loïc Joly wrote:
Fine by me. Thanks

endif::env-github,rspecator-view[]