On the function of "Boolean parameter as entry"

Clean Code has a very moving description of how to write good functions, with the following two suggestions for function parameters:

• The number of function arguments should be as few as possible
• To pass a unary function to a parameter of type bool "evil."

When I browsed Hacker news yesterday, I found an article referring to the 2nd above, the discussion of "Boolean parameters". So combined with this article, a brief summary to deepen the impression.

For the description of clean Code in 3.6.2, passing a Boolean parameter to a function is obviously a declaration that the function does more than one thing, which is clearly contrary to the "function only thing" advocated in the book. That said, it didn't make me very "impressed" by the fact that I didn't have a rich coding experience. On the contrary, I have written such a function very seriously, because that function so that the implementation looks a little bit of charm, can "with an enemy double" is not very cool practice, and the function itself is very short, I did not want to divide it into two functions to write-perhaps after that, When you encounter a similar situation, you will have a slight discretion.

As mentioned in the article, the title is "Boolean parameters to API functions considered harmful". Obviously, the author also mentions that it is undesirable to plug a function into a Boolean parameter, because when a function is used as an API, it is difficult for the user to correspond to the functionality implemented in the specific API, as in the example in this article: True/false.

// open的第三个参数为Boolean类型，确定是否以async/sync的方式打开，但是option当中的值未必与open内部的操作相对应。    _xhr.open(options.type, options.url, options.sync);// AddObserver的第三个参数为Boolean类型，其对应的true/false具体意味着什么显得很模糊mDocument->AddObserver(observer, "load", true);

This can be done by optimizing it:

// 此时openAsync很明显的告之了以async的方式打开。xhr.openAsync(options.type, options.url)// 接口AddWeakObserver提示了增添weak的ObservermDocument.AddWeakObserver(observer, "load");

For example, the two example, the latter looks clearer, its function directly expresses the main responsibilities of the interface, which is the clean code of the proposed practice. Of course, it is not necessary for this practice, it will have to vary from person to person, because of different teams. It is very simple to cite a counter-example to prove that this is not necessary, such as setvisiblity (false) in the author's text.

In general, in terms of the function naming and interface design, it is a matter of pursuing and learning to make code more natural and clear. It is also to be mentioned that the current proposal, only for their own knowledge of the strong type of language C/c++/java, other languages are not special, another matter.

On the function of "Boolean parameter as entry"