blocks|key|362668|text|枚举还允许将来进行修改，您现在需要第三种选择(或更多)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362669|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Enums also allow for future modifications, where you now want a third choice (or more).

blocks|key|3153978|text|只有当您不打算扩展框架的功能时，布尔值才是可接受的。枚举是首选的，因为您可以扩展枚举，而不会中断函数调用的先前实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153979|枚举的另一个优点是更容易阅读。|3153980|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A Boolean would only be acceptable if you do not intend to extend the functionality of the framework. The Enum is preferred because you can extend the enum and not break previous implementations of the function call. 

The other advantage of the Enum is that is easier to read.

blocks|key|3153988|text|布尔值表示“是/否”的选择。如果你想表示一个"yes/no"，那么使用一个布尔值，它应该是不言而喻的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153989|但如果是在两个选项之间进行选择，而这两个选项都不是明确的yes或no，那么枚举有时会更具可读性。|3153990|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Boolean's represent "yes/no" choices. If you want to represent a "yes/no", then use a boolean, it should be self-explanatory.

But if it's a choice between two options, neither of which is clearly yes or no, then an enum can sometimes be more readable.

blocks|key|3153995|text|我认为你自己几乎回答了这个问题，我认为最终目标是使代码更具可读性，在这种情况下，枚举做到了这一点，最好总是着眼于最终目标，而不是笼统的规则，也许更多地将其视为指导原则，即枚举通常比泛型bools、in等在代码中更具可读性，但规则总是会有例外。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153996|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think you almost answered this yourself, I think the end aim is to make the code more readable, and in this case the enum did that, IMO its always best to look at the end aim rather than blanket rules, maybe think of it more as a guideline i.e. enums are often more readable in code than generic bools, ints etc but there will always be exceptions to the rule.

blocks|key|3367000|text|枚举更好，但我不认为布尔参数是“不可接受的”。有时，抛出一个小布尔值并继续前进(考虑私有方法等)会更容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3367001|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Enums are better but I wouldn't call boolean params as "unacceptable". Sometimes it's just easier to throw one little boolean in and move on (think private methods etc.)

blocks|key|365966|text|如果该方法提出如下问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365967|KeepWritingData+(DataAvailable());|code-block|syntax|javascript|365968|哪里|365969|bool+DataAvailable()
{
++++return+true;+//data+is+ALWAYS+available!
}

void+KeepWritingData+(bool+keepGoing)
{
+++if+(keepGoing)
+++{
+++++++...
+++}
}|365970|布尔方法参数看起来非常有意义。|365971|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

If the method asks a question such as:

<pre><code>KeepWritingData (DataAvailable());
</code></pre>

where

<pre><code>bool DataAvailable()
{
 return true; //data is ALWAYS available!
}

void KeepWritingData (bool keepGoing)
{
 if (keepGoing)
 {
 ...
 }
}
</code></pre>

boolean method arguments seem to make absolutely perfect sense.

blocks|key|361230|text|这取决于方法。如果方法做的事情很明显是真/假的，那么它就很好，例如，下面虽然不是我说这是这个方法的最佳设计，这只是一个例子，用法是显而易见的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361231|CommentService.SetApprovalStatus(commentId,+false);|code-block|syntax|javascript|361232|但是，在大多数情况下，例如您提到的示例，最好使用枚举。在.NET框架本身中有许多不遵循此约定的示例，但这是因为他们在周期中较晚引入了此设计指导原则。|361233|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

It depends on the method. If the method does something that is very obviously a true/false thing then it is fine, e.g. below [though not I am not saying this is the best design for this method, it's just an example of where the usage is obvious].

<pre><code>CommentService.SetApprovalStatus(commentId, false);
</code></pre>

However in most cases, such as the example you mention, it is better to use an enumeration. There are many examples in the .NET Framework itself where this convention is not followed, but that is because they introduced this design guideline fairly late on in the cycle.

blocks|key|3154044|text|如果有两种以上的选择，枚举似乎是显而易见的选择。但在某些情况下，只需要一个布尔值就可以了。在这种情况下，我会说在bool可以工作的情况下使用枚举将是一个使用7个单词的示例，而4个单词也可以。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154045|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

IMHO it seems like an enum would be the obvious choice for any situation where more than two options are possible. But there definitely ARE situations where a boolean is all you need. In that case I would say that using an enum where a bool would work would be an example of using 7 words when 4 will do.

blocks|key|3154054|text|当你有一个明显的切换时，布尔值是有意义的，它只能是两件事中的一件(即灯泡的状态，开还是关)。除此之外，以这样一种方式编写它是很好的，即您正在传递的内容是显而易见的-例如，磁盘写入-无缓冲、行缓冲或同步-应该这样传递。即使您现在不想允许同步写入(因此您被限制为两个选项)，也值得考虑使它们变得更详细，以便第一眼就知道它们做了什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154055|也就是说，您还可以使用False和True+(布尔值0和1)，然后如果以后需要更多值，则扩展函数以支持用户定义的值(例如，2和3)，这样您的旧0/1值就可以很好地移植，因此您的代码不应该中断。|3154056|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Booleans make sense when you have an obvious toggle which can only be one of two things (i.e. the state of a light bulb, on or off). Other than that, it's good to write it in such a way that it's obvious what you're passing - e.g. disk writes - unbuffered, line-buffered, or synchronous - should be passed as such. Even if you don't want to allow synchronous writes now (and so you're limited to two options), it's worth considering making them more verbose for the purposes of knowing what they do at first glance.

That said, you can also use False and True (boolean 0 and 1) and then if you need more values later, expand the function out to support user-defined values (say, 2 and 3), and your old 0/1 values will port over nicely, so your code ought not to break.

blocks|key|3367079|text|它确实让事情变得更加明确，但也开始大量地扩展你的接口的复杂性--在纯粹的布尔选择中，比如追加/覆盖，它看起来有点过分了。如果您需要添加进一步的选项(在这种情况下我想不到)，您可以随时执行重构(取决于语言)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3367080|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It does make things a bit more explicit, but does start to massively extend the complexity of your interfaces - in a sheer boolean choice such as appending/overwriting it seems like overkill. If you need to add a further option (which I can't think of in this case), you can always perform a refactor (depending on the language)

blocks|key|362746|text|我不同意这是一个好的规则。显然，Enum在某些情况下提供了更好的显式或冗长的代码，但作为一种规则，它似乎远远超出了实现的范围。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|362747|首先，让我以您的例子为例:程序员编写良好代码的责任(和能力)并不会因为具有布尔参数而受到真正的影响。在您的示例中，程序员可以通过编写以下代码来编写详细的代码：|362748|dim+append+as+boolean+=+true
file.writeData(+data,+append+);|code-block|syntax|javascript|362749|或者我更喜欢更一般的|362750|dim+shouldAppend+as+boolean+=+true
file.writeData(+data,+shouldAppend+);|362751|第二:您给出的枚举示例只是“更好”，因为您传递的是一个CONST。在大多数应用程序中，传递给函数的时间参数很可能是变量。在这种情况下，我的第二个示例(给变量起好名字)要好得多，而Enum不会给您带来什么好处。|362752|entityMap^0|A|2|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|10|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|11|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|T|$]]

I would not agree that it is a good rule. Obviously, Enum makes for a better explicit or verbose code at some instances, but as a rule it seems way over reaching. 

First let me take your example:
The programmers responsibility (and ability) to write good code is not really jeopardized by having a Boolean parameter. In your example the programmer could have written just as verbose code by writing:

<pre><code>dim append as boolean = true
file.writeData( data, append );
</code></pre>

or I prefer more general

<pre><code>dim shouldAppend as boolean = true
file.writeData( data, shouldAppend );
</code></pre>

Second:
The Enum example you gave is only "better" because you are passing a CONST. Most likely in most application at least some if not most of the time parameters that are passed to functions are VARIABLES. in which case my second example (giving variables with good names) is much better and Enum would have given you little benefits.

blocks|key|361251|text|使用对您的问题建模最好的模型。在您给出的示例中，枚举是更好的选择。但是，在其他情况下，布尔值更好。对你来说更有意义的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361252|lock.setIsLocked(True);|code-block|syntax|javascript|361253|或|361254|enum+LockState+{+Locked,+Unlocked+};
lock.setLockState(Locked);|361255|在这种情况下，我可能会选择布尔选项，因为我认为它非常清晰明确，而且我非常确定我的锁不会有两个以上的状态。尽管如此，第二个选择是有效的，但不必要地复杂，IMHO。|361256|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Use the one that best models your problem. In the example you give, the enum is a better choice. However, there would be other times when a boolean is better. Which makes more sense to you:

<pre><code>lock.setIsLocked(True);
</code></pre>

or

<pre><code>enum LockState { Locked, Unlocked };
lock.setLockState(Locked);
</code></pre>

In this case, I might choose the boolean option since I think it's quite clear and unambiguous, and I'm pretty sure my lock is not going to have more than two states. Still, the second choice is valid, but unnecessarily complicated, IMHO.

blocks|key|3154214|text|还记得阿德莱·史蒂文森在cuban+missile+crisis期间向佐林大使提出的问题吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3154215|3154216|“你现在正站在世界舆论的法庭上，你可以回答yes或no。你否认导弹的存在，我想知道我是否正确理解了你的意思……我准备等待我的答案，直到地狱冻结，如果这是你的决定。”|blockquote|style|BOLD|3154217|3154218|3154219|如果您的方法中的标志具有这样一种性质，即您可以将其绑定到二元决策，并且该决策将永远不会转变为三向或n向决策，请使用布尔值。提示:您的旗帜名为isXXX。|3154220|如果是模式开关，请不要将其设为布尔值。总是有比你一开始编写方法时所想的多一个模式的。|3154221|一个多模式的困境，例如闹鬼的Unix，其中可能的权限模式，文件或目录今天可能导致奇怪的双重含义的模式取决于文件类型，所有权等。|3154222|entityMap|0|LINK|mutability|MUTABLE|url|http://answers.google.com/answers/threadview/id/765433.html^0|C|K|0|0|0|L|6|0|0|0|S|4|1Y|5|0|3|4|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|D|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|14|8|@$A|15|B|16|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|18|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|19|8|@$A|1A|B|1B|H|I]|$A|1C|B|1D|H|I]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1E|8|@$A|1F|B|1G|H|I]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1H|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]]|S|$T|$5|U|V|W|C|$X|Y]]]]

Remember the question Adlai Stevenson posed to ambassador Zorin at the U.N. during the <a href="http://answers.google.com/answers/threadview/id/765433.html" rel="noreferrer">cuban missile crisis</a>?

<blockquote>
 "You are in the courtroom of world
 opinion right now, and you can answer
 yes or no. You have denied that [the missiles]
 exist, and I want to know whether I
 have understood you correctly.... I am
 prepared to wait for my answer until
 hell freezes over, if that's your
 decision."
</blockquote>

If the flag you have in your method is of such a nature that you can pin it down to a binary decision, and that decision will never turn into a three-way or n-way decision, go for boolean. Indications: your flag is called isXXX. 

Don't make it boolean in case of something that is a mode switch. There is always one more mode than you thought of when writing the method in the first place. 

The one-more-mode dilemma has e.g. haunted Unix, where the possible permission modes a file or directory can have today result in weird double meanings of modes depending on file type, ownership etc.

blocks|key|3154362|text|布尔值在具有命名参数的语言中可能是可以的，比如Python和Objective-C，因为名称可以解释参数的作用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154363|file.writeData(data,+overwrite=true)|code-block|syntax|javascript|3154364|或者：|3154365|[file+writeData:data+overwrite:YES]|3154366|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Booleans may be OK in languages that have named parameters, like Python and Objective-C, since the name can explain what the parameter does:

<pre><code>file.writeData(data, overwrite=true)
</code></pre>

or:

<pre><code>[file writeData:data overwrite:YES]
</code></pre>

blocks|key|3154501|text|有两个原因让我发现这是一件坏事：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154502|3154503|，因为有些人会写这样的方法：|ordered-list-item|3154504|3154505|ProcessBatch(true，false，false，true，false，false，true)；|3154506|这显然很糟糕，因为它太容易混淆参数，而且您无法通过查看它来了解您指定的是什么。只有一个布尔值并不是太糟糕，though.|3154507|Because通过一个简单的是/否分支控制程序流可能意味着你有两个完全不同的函数，它们以一种笨拙的方式被包装成一个函数。例如：|unordered-list-item|3154508|3154509|public+void+(布尔toOptical)；|3154510|实际上，这应该是两种方法|3154511|public+void+WriteOptical()；public+void+WriteMagnetic()；|3154512|因为它们中的代码可能完全不同；它们可能必须进行各种不同的错误处理和验证，甚至可能必须以不同的方式格式化输出数据。仅仅使用Write()甚至Write(Enum.Optical)是不可能做到这一点的(当然，您也可以使用这两个方法中的任何一个，如果您愿意，只需调用内部方法WriteOptical/Mag即可)。|offset|length|style|CODE|3154513|我想这要看情况了。我不会对此小题大做，除了#1。|3154514|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|1O|7|1X|J|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|16|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|18|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|19|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1A|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@$W|1G|X|1H|Y|Z]|$W|1I|X|1J|Y|Z]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1K|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|13|$]]

There are two reasons I've run into this being a bad thing:

<ol>
<li>Because some people will write methods like:

<pre><code>ProcessBatch(true, false, false, true, false, false, true);
</code></pre>

This is obviously bad because it's too easy to mix up parameters, and you have no idea by looking at it what you're specifying. Just one bool isn't too bad though.</li>
<li>Because controlling program flow by a simple yes/no branch might mean you have two entirely different functions that are wrapped up into one in an awkard way. For instance:

<pre><code>public void Write(bool toOptical);
</code></pre>

Really, this should be two methods

<pre><code>public void WriteOptical();
public void WriteMagnetic();
</code></pre>

because the code in these might be entirely different; they might have to do all sorts of different error handling and validation, or maybe even have to format the outgoing data differently. You can't tell that just by using <code>Write()</code> or even <code>Write(Enum.Optical)</code> (though of course you could have either of those methods just call internal methods WriteOptical/Mag if you want).</li>
</ol>

I guess it just depends. I wouldn't make too big of a deal about it except for #1.

blocks|key|363404|text|枚举有一个明确的好处，但您不应该仅仅用枚举替换所有的布尔值。在许多地方，true/false实际上是表示正在发生的事情的最佳方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363405|但是，使用它们作为方法参数有点可疑，因为如果不深入研究它们应该做什么，就无法看到它们应该做什么，因为它们让您看到true/false的实际含义|363406|属性(特别是使用C#3对象初始值设定项)或关键字参数(类似于ruby或python)是使用布尔参数的更好方法。|363407|C#示例：|363408|var+worker+=+new+BackgroundWorker+{+WorkerReportsProgress+=+true+};|code-block|syntax|javascript|363409|Ruby示例|363410|validates_presence_of+:name,+:allow_nil+=>+true|363411|Python示例|363412|connect_to_database(+persistent=true+)|363413|我唯一能想到的是在java中使用布尔方法参数是正确的，因为在java中既没有属性参数，也没有关键字参数。这是我讨厌java的原因之一:-(|363414|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|16|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Enums have a definite benefit, but you should't just go replacing all your booleans with enums. There are many places where true/false is actually the best way to represent what is going on.

However, using them as method arguments is a bit suspect, simply because you can't see without digging into things what they are supposed to do, as they let you see what the true/false actually means

Properties (especially with C#3 object initializers) or keyword arguments (a la ruby or python) are a much better way to go where you'd otherwise use a boolean argument.

C# example:

<pre><code>var worker = new BackgroundWorker { WorkerReportsProgress = true };
</code></pre>

Ruby example

<pre><code>validates_presence_of :name, :allow_nil =&gt; true
</code></pre>

Python example

<pre><code>connect_to_database( persistent=true )
</code></pre>

The only thing I can think of where a boolean method argument is the right thing to do is in java, where you don't have either properties or keyword arguments. This is one of the reasons I hate java :-(

blocks|key|3154674|text|枚举当然可以使代码更具可读性。仍然有一些事情需要注意(至少在.net中)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154675|因为枚举的底层存储是int，所以默认值将是零，因此您应该确保0是合理的默认值。(例如，结构在创建时将所有字段设置为零，因此无法指定除0以外的默认值。如果没有0值，您甚至无法在不转换为int的情况下测试枚举，这将是一种糟糕的风格。)|3154676|如果你的枚举对你的代码是私有的(从未公开)，那么你可以在这里停止阅读。|3154677|如果您的枚举以任何方式发布到外部代码和/或保存在程序外部，请考虑显式地对它们进行编号。编译器会自动从0开始对它们进行编号，但是如果您重新排列枚举而没有给它们赋值，那么您可能会以缺陷告终。|3154678|我可以合法地写|3154679|WriteMode+illegalButWorks+=+(WriteMode)1000000;
file.Write(+data,+illegalButWorks+);|code-block|syntax|javascript|3154680|为了解决这个问题，任何使用你不能确定的枚举的代码(例如公共API)都需要检查该枚举是否有效。您可以通过|3154681|if+(!Enum.IsDefined(typeof(WriteMode),+userValue))
++++throw+new+ArgumentException("userValue");|3154682|Enum.IsDefined唯一的警告是它使用反射，而且速度更慢。它还存在版本控制问题。如果您需要经常检查枚举值，最好执行以下操作：|offset|length|style|CODE|3154683|public+static+bool+CheckWriteModeEnumValue(WriteMode+writeMode)
{
++switch(+writeMode+)
++{
++++case+WriteMode.Append:
++++case+WriteMode.OverWrite:
++++++break;
++++default:
++++++Debug.Assert(false,+"The+WriteMode+'"+%2B+writeMode+%2B+"'+is+not+valid.");
++++++return+false;
++}
++return+true;
}|3154684|版本控制的问题是，旧代码可能只知道如何处理您拥有的2个枚举。如果添加第三个值，Enum.IsDefined将为true，但旧代码不一定能处理它。哇哦。|3154685|使用[Flags]枚举可以做更多有趣的事情，并且验证代码略有不同。|3154686|我还会注意到，为了便于移植，您应该在枚举上使用call+ToString()，并在读回它们时使用Enum.Parse()。ToString()和Enum.Parse()都可以处理[Flags]枚举，所以没有理由不使用它们。注意，这是另一个陷阱，因为现在您甚至不能在不破坏代码的情况下更改枚举的名称。|3154687|所以，有时你需要权衡以上所有的问题，当你问自己，我能不能只用一个bool就可以了？|3154688|entityMap^0|0|0|0|0|0|0|0|0|0|E|0|0|0|2|7|0|S|A|1C|C|1P|A|20|C|2H|7|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1C|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1F|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|1H|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1I|8|@$U|1J|V|1K|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|1L|8|@]|9|@]|A|$M|N]]|$1|10|3|11|5|6|7|1M|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1N|8|@$U|1O|V|1P|W|X]]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Q|8|@$U|1R|V|1S|W|X]|$U|1T|V|1U|W|X]|$U|1V|V|1W|W|X]|$U|1X|V|1Y|W|X]|$U|1Z|V|20|W|X]]|9|@]|A|$]]|$1|16|3|17|5|6|7|21|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|19|$]]

Enums can certainly make the code more readable. There are still a few things to watch out for (in .net at least)

Because the underlying storage of an enum is an int, the default value will be zero, so you should make sure that 0 is a sensible default. (E.g. structs have all fields set to zero when created, so there's no way to specify a default other than 0. If you don't have a 0 value, you can't even test the enum without casting to int, which would be bad style.)

If your enum's are private to your code (never exposed publicly) then you can stop reading here.

If your enums are published in any way to external code and/or are saved outside of the program, consider numbering them explicitly. The compiler automatically numbers them from 0, but if you rearrange your enums without giving them values you can end up with defects.

I can legally write

<pre><code>WriteMode illegalButWorks = (WriteMode)1000000;
file.Write( data, illegalButWorks );
</code></pre>

To combat this, any code that consumes an enum that you can't be certain of (e.g. public API) needs to check if the enum is valid. You do this via

<pre><code>if (!Enum.IsDefined(typeof(WriteMode), userValue))
 throw new ArgumentException("userValue");
</code></pre>

The only caveat of <code>Enum.IsDefined</code> is that it uses reflection and is slower. It also suffers a versioning issue. If you need to check the enum value often, you would be better off the following:

<pre><code>public static bool CheckWriteModeEnumValue(WriteMode writeMode)
{
 switch( writeMode )
 {
 case WriteMode.Append:
 case WriteMode.OverWrite:
 break;
 default:
 Debug.Assert(false, "The WriteMode '" + writeMode + "' is not valid.");
 return false;
 }
 return true;
}
</code></pre>

The versioning issue is that old code may only know how to handle the 2 enums you have. If you add a third value, Enum.IsDefined will be true, but the old code can't necessarily handle it. Whoops.

There's even more fun you can do with <code>[Flags]</code> enums, and the validation code for that is slightly different.

I'll also note that for portability, you should use call <code>ToString()</code> on the enum, and use <code>Enum.Parse()</code> when reading them back in. Both <code>ToString()</code> and <code>Enum.Parse()</code> can handle <code>[Flags]</code> enum's as well, so there's no reason not to use them. Mind you, it's yet another pitfall, because now you can't even change the name of the enum without possibly breaking code.

So, sometimes you need to weigh all of the above in when you ask yourself Can I get away with just an bool?

blocks|key|3367718|text|这真的取决于争论的确切性质。如果不是yes/no或true/false，则枚举使其更具可读性。但是使用枚举时，您需要检查参数或具有可接受的默认行为，因为可以传递底层类型的未定义的值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3367719|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It really depends on the exact nature of the argument. If it is not a yes/no or true/false then a enum makes it more readable. But with an enum you need to check the argument or have acceptable default behaviour since undefined values of the underlying type can be passed.

blocks|key|3154711|text|虽然在许多情况下枚举确实比布尔型更具可读性和可扩展性，但“布尔型是不可接受的”的绝对规则是愚蠢的。它是僵化和适得其反的--它没有为人类的判断留下空间。在大多数语言中，它们是基本的内置类型，因为它们很有用-考虑将其应用于其他内置类型:例如，说“永远不要使用int作为参数”就太疯狂了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154712|这条规则只是一个风格问题，而不是潜在的bug或运行时性能问题。一个更好的规则应该是“出于可读性的原因，更喜欢枚举而不是布尔型”。|3154713|看看.Net框架。在相当多的方法中，布尔值被用作参数。boolean+API并不完美，但我认为使用.Net作为参数并不是一个大问题。工具提示总是给出参数的名称，您也可以构建这样的指导--在方法参数上填写XML注释，它们将出现在工具提示中。|3154714|我还应该补充的是，在某些情况下，您应该清楚地将布尔值重构为枚举-当您的类或方法参数中有两个或更多布尔值，并且不是所有状态都有效时(例如，将它们都设置为true不是有效的)。|3154715|例如，如果您的类具有如下属性|3154716|public+bool+IsFoo
public+bool+IsBar|code-block|syntax|javascript|3154717|同时让这两个状态都为真是错误的，你实际得到的是三个有效的状态，更好地表达为：|3154718|enum+FooBarType+{+IsFoo,+IsBar,+IsNeither+};|3154719|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|11|8|@]|9|@]|A|$M|N]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

While it is true that in many cases enums are more readable and more extensible than booleans, an absolute rule that "booleans are not acceptable" is daft. It is inflexible and counter-productive - it does not leave room for human judgement. They're a fundamental built in type in most languages because they're useful - consider applying it to other built-in-types: saying for instance "never use an int as a parameter" would just be crazy.

This rule is just a question of style, not of potential for bugs or runtime performance. A better rule would be "prefer enums to booleans for reasons of readability".

Look at the .Net framework. Booleans are used as parameters on quite a few methods. The .Net API is not perfect, but I don't think that the use of boolean as parameters is a big problem. The tooltip always gives you the name of the parameter, and you can build this kind of guidance too - fill in your XML comments on the method parameters, they will come up in the tooltip.

I should also add that there is a case when you should clearly refactor booleans to an enumeration - when you have two or more booleans on your class, or in your method params, and not all states are valid (e.g. it's not valid to have them both set true).

For instance, if your class has properties like

<pre><code>public bool IsFoo
public bool IsBar
</code></pre>

And it's an error to have both of them true at the same time, what you've actually got is three valid states, better expressed as something like:

<pre><code>enum FooBarType { IsFoo, IsBar, IsNeither };
</code></pre>

blocks|key|363531|text|在示例中使用枚举而不是布尔值确实有助于提高方法调用的可读性。但是，这是C#中我最喜欢的愿望项的替代品，即方法调用中的命名参数。此语法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363532|var+v+=+CallMethod(pData+=+data,+pFileMode+=+WriteMode,+pIsDirty+=+true);|code-block|syntax|javascript|363533|将是完全可读的，然后您可以做程序员应该做的事情，即为方法中的每个参数选择最合适的类型，而不考虑它在IDE中的外观。|363534|C#+3.0允许在构造函数中使用命名参数。我不知道为什么他们不能用方法来做到这一点。|363535|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The use of enums instead of booleans in your example does help make the method call more readable. However, this is a substitute for my favorite wish item in C#, named arguments in method calls. This syntax:

<pre><code>var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);
</code></pre>

would be perfectly readable, and you could then do what a programmer should do, which is choose the most appropriate type for each parameter in the method without regard to how it looks in the IDE.

C# 3.0 allows named arguments in constructors. I don't know why they can't do this with methods as well.

blocks|key|363558|text|有时，使用重载对不同的行为进行建模会更简单。从您的示例继续，将是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363559|file.appendData(+data+);++
file.overwriteData(+data+);|code-block|syntax|javascript|363560|如果您有多个参数，每个参数都允许一组固定的选项，则此方法会降级。例如，打开文件的方法可能有文件模式(打开/创建)、文件访问(读/写)、共享模式(无/读/写)的几种排列。配置的总数等于各个选项的笛卡尔乘积。当然，在这种情况下，多个重载是不合适的。|363561|在某些情况下，枚举可以使代码更具可读性，尽管在某些语言(例如C#)中验证确切的枚举值可能很困难。|363562|通常，布尔参数作为新的重载附加到参数列表中。.NET中的一个示例是：|363563|Enum.Parse(str);++
Enum.Parse(str,+true);+//+ignore+case|363564|后一个重载在比第一个版本更晚的.NET框架中可用。|363565|如果您知道只有两个选择，那么布尔值可能就可以了。枚举是可扩展的，不会破坏旧代码，尽管旧的库可能不支持新的枚举值，因此不能完全忽略版本控制。|363566|363567|编辑|offset|length|style|BOLD|363568|在较新版本的C#中，可以使用命名参数，这可以使调用代码更加清晰，就像枚举一样。使用与上面相同的示例：|363569|Enum.Parse(str,+ignoreCase:+true);|363570|entityMap^0|0|0|0|0|0|0|0|0|0|0|2|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|16|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1A|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1E|8|@$V|1F|W|1G|X|Y]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1H|8|@]|9|@]|A|$]]|$1|11|3|12|5|D|7|1I|8|@]|9|@]|A|$E|F]]|$1|13|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|14|$]]

Sometimes it's just simpler to model different behaviour with overloads. To continue from your example would be:

<pre><code>file.appendData( data ); 
file.overwriteData( data );
</code></pre>

This approach degrades if you have multiple parameters, each allowing a fixed set of options. For example, a method that opens a file might have several permutations of file mode (open/create), file access (read/write), sharing mode (none/read/write). The total number of configurations is equal to the Cartesian products of the individual options. Naturally in such cases multiple overloads are not appropriate. 

Enums can, in some cases make code more readable, although validating the exact enum value in some languages (C# for example) can be difficult.

Often a boolean parameter is appended to the list of parameters as a new overload. One example in .NET is:

<pre><code>Enum.Parse(str); 
Enum.Parse(str, true); // ignore case
</code></pre>

The latter overload became available in a later version of the .NET framework than the first.

If you know that there will only ever be two choices, a boolean might be fine. Enums are extensible in a way that won't break old code, although old libraries might not support new enum values so versioning cannot be completely disregarded.

<hr>

EDIT

In newer versions of C# it's possible to use named arguments which, IMO, can make calling code clearer in the same way that enums can. Using the same example as above:

<pre><code>Enum.Parse(str, ignoreCase: true);
</code></pre>

blocks|key|363156|text|对我来说，使用布尔值和枚举都不是好方法。Robert+C.+Martin在他的Clean+Code+Tip+#12:+Eliminate+Boolean+Arguments中非常清楚地捕捉到了这一点|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|363157|363158|布尔参数响亮地声明函数做了不止一件事。它们令人困惑，应该被消除。|blockquote|363159|363160|363161|如果一个方法不止做一件事，你应该写两个不同的方法，例如在你的例子中：file.append(data)和file.overwrite(data)。|style|CODE|363162|使用枚举并不能让事情变得更清楚。它不会改变任何事情，它仍然是一个旗帜参数。|363163|entityMap|0|LINK|mutability|MUTABLE|url|http://www.informit.com/articles/article.aspx?p=1392524^0|13|1B|0|0|0|0|0|0|Y|H|1G|K|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|15|8|@$A|16|B|17|L|M]|$A|18|B|19|L|M]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1A|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]]]

To me, neither using boolean nor enumeration is a good approach. Robert C. Martin captures this very clearly in his <a href="http://www.informit.com/articles/article.aspx?p=1392524" rel="noreferrer">Clean Code Tip #12: Eliminate Boolean Arguments</a>:

<blockquote>
 Boolean arguments loudly declare that the function does more than one thing. They are confusing and should be eliminated.
</blockquote>

If a method does more than one thing, you should rather write two different methods, for example in your case: <code>file.append(data)</code> and <code>file.overwrite(data)</code>.

Using an enumeration doesn't make things clearer. It doesn't change anything, it's still a flag argument.

blocks|key|3154921|text|你的同事最好遵守以下规则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3154922|3154923|不要教条地对待你的设计。|unordered-list-item|3154924|选择最适合你的代码用户的代码。|3154925|不要试图仅仅因为你喜欢这个月的形状就把每个洞都钉上星形！|3154926|3154927|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

Some rules that your colleague might be better adhering to are: 

<ul>
<li>Don't be dogmatic with your design. </li>
<li>Choose what fits most appropriately for the users of your code.</li>
<li>Don't try to bash star-shaped pegs into every hole just because you like the shape this month!</li>
</ul>

blocks|key|361736|text|布尔值仅为true/false。所以目前还不清楚它代表了什么。Enum可以有有意义的名字，例如OVERWRITE，APPEND等，所以枚举更好。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|361737|entityMap^0|5|4|A|5|V|4|1B|9|1L|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|G|$]]

Booleans values <code>true</code>/<code>false</code> only. So it is not clear what it represent. <code>Enum</code> can have meaningful name, e.g <code>OVERWRITE</code>, <code>APPEND</code>, etc. So enums are better.

blocks|key|3368019|text|我确实同意枚举是一种很好的方法，在方法中你有两个选项(只有两个选项你可以在没有枚举的情况下具有可读性)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3368020|例如：|3368021|public+void+writeData(Stream+data,+boolean+is_overwrite)|code-block|syntax|javascript|3368022|我喜欢枚举，但布尔值也很有用。|3368023|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Where I do agree that Enums are good way to go, in methods where you have 2 options (and just two options you can have readability without enum.)

e.g.

<pre><code>public void writeData(Stream data, boolean is_overwrite)
</code></pre>

Love the Enums, but boolean is useful too.

blocks|key|363223|text|这是一个旧帖子的晚期条目，而且它是如此之深，以至于没有人会读到它，但因为没有人已经说过了……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363224|内联注释对解决意想不到的bool问题大有帮助。最初的例子尤其令人发指:想象一下在函数解析中尝试命名变量！它应该是这样的|offset|length|style|CODE|363225|void+writeData(+DataObject+data,+bool+use_append_mode+);|code-block|syntax|javascript|363226|但是，为了举例，我们假设这就是声明。然后，对于一个无法解释的布尔参数，我将变量名放在一个内联注释中。比较|363227|file.writeData(+data,+true+);|363228|使用|363229|file.writeData(+data,+true+/*+use_append_mode+*/);|363230|entityMap^0|0|C|4|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

This is a late entry on an old post, and it's so far down the page that nobody will ever read it, but since nobody has said it already....

An inline comment goes a long way to solving the unexpected <code>bool</code> problem. The original example is particularly heinous: imagine trying to name the variable in the function declearation! It'd be something like

<pre><code>void writeData( DataObject data, bool use_append_mode );
</code></pre>

But, for the sake of example, let's say that's the declaration. Then, for an otherwise unexplained boolean argument, I put the variable name in an inline comment. Compare

<pre><code>file.writeData( data, true );
</code></pre>

with

<pre><code>file.writeData( data, true /* use_append_mode */);
</code></pre>

A colleague of mine states that booleans as method arguments are not acceptable. They shall be replaced by enumerations. At first I did not see any benefit, but he gave me an example.

What's easier to understand?

<pre><code>file.writeData( data, true );
</code></pre>

Or

<pre><code>enum WriteMode {
 Append,
 Overwrite
};

file.writeData( data, Append );
</code></pre>

Now I got it! ;-) 
This is definitely an example where an enumeration as second parameter makes the code much more readable.

So, what's your opinion on this topic?

Are booleans as method arguments unacceptable?

Objective-C

编译器

Python

Unix

我的一位同事指出，作为方法参数的布尔值是不可接受的。它们将被枚举所取代。起初，我没有看到任何好处，但他给了我一个例子。哪一个更容易理解？file.writeData( data, true );或enum WriteMode {  Append,  Overwrite};file.writeData( data, Ap...

问布尔值作为方法参数是不可接受的吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问布尔值作为方法参数是不可接受的吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问布尔值作为方法参数是不可接受的吗？
EN