在代码中经常使用标志是否可取？

发布于 2024-07-18 11:22:35 字数 225 浏览 12 评论 0原文

我在阅读别人的代码时遇到了很多标志，

if (condition1) 
    var1 = true
else
    var1 = false

后来，

if (var1 == true)
    // do something.

有很多这样的标志。我很想知道，在代码中经常使用标志是否明智？

原文

I came across lot of flags while reading someone else code,

if (condition1) 
    var1 = true
else
    var1 = false

then later,

if (var1 == true)
    // do something.

There are lot of flags like this. I eager to know, is using flags very often in code advisable?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一曲爱恨情仇 2024-07-25 11:22:35

这

if (condition1)
   var1= true;
else
   var1 = false;

是一个典型的写得很糟糕的代码。
相反，你应该这样写：

var1 = condition1;

是的，标志对于使代码更具可读性并且可能更快非常有用。

This:

if (condition1)
   var1= true;
else
   var1 = false;

Is a classic badly written code.
Instead you should write:

var1 = condition1;

And yes, flags are very useful for making the code be more readable and possibly, faster.

回复收藏 0 原文

乄_柒ぐ汐 2024-07-25 11:22:35

如果 condition1 非常复杂 - 例如 if (A && (B || C) && !D) 或包含大量开销，这是明智的(if (somethingTimeConsumingThatWontChange())) 那么存储该结果而不是复制粘贴代码是有意义的。

如果 condition1 只是一个简单的比较，那么不，我不会使用标志。

回复收藏 0 原文

小女人ら 2024-07-25 11:22:35

这是相当主观的，取决于代码的其余部分。你们所说的“旗帜”有其用武之地。

回复收藏 0 原文

为人所爱 2024-07-25 11:22:35

首先，这段代码应该是这样的：

var1 = condition1;

if( var1 )

// No need to compare *true* to *true* when you're looking for *true*

至于标志的数量，有更优雅的方式来分支代码。例如，当使用 javascript 时，您可以执行以下操作：

var methodName = someFunctionThatReturnsAString();

// assuming you name the method according to what's returned
myObject[ methodName ]();

而不是

if( someFunctionThatReturnsAString === 'myPreferedMethod' ){
    myObject.myPreferedMethod();
}else{
    myObject.theOtherMethod();
}

如果您使用的是强类型语言，多态性是您的朋友，这样。我认为该技术被称为多态调度

First of all, this code should read like this:

var1 = condition1;

if( var1 )

// No need to compare *true* to *true* when you're looking for *true*

As for the number of flags, there are more elegant ways of branching your code. For instance , when using javascript you can do stuff like this:

var methodName = someFunctionThatReturnsAString();

// assuming you name the method according to what's returned
myObject[ methodName ]();

instead of

if( someFunctionThatReturnsAString === 'myPreferedMethod' ){
    myObject.myPreferedMethod();
}else{
    myObject.theOtherMethod();
}

If you're using a strongly typed language, polymorphism is your friend. I think the technique is refered to as polymorphic dispatch

回复收藏 0 原文

过期情话 2024-07-25 11:22:35

我记得重构书中的用查询方法替换临时变量。
我认为这种重构将使代码更具可读性，但是，我同意当查询方法昂贵时它可能会影响性能......（但是，也许查询方法可以放在它自己的类中，并且可以缓存结果进入该班级）。

回复收藏 0 原文

感情废物 2024-07-25 11:22:35

这个问题有点笼统。答案取决于您想要做什么以及您希望它使用哪种语言。假设面向对象的上下文可能有更好的方法。

如果条件是某个对象状态的结果，那么“标志”可能应该是对象本身的属性。如果这是正在运行的应用程序的一个条件，并且您有很多这样的东西，那么您可能应该考虑状态模式/状态机。

回复收藏 0 原文

画离情绘悲伤 2024-07-25 11:22:35

标志非常有用，但要给它们起合理的名称，例如在名称中使用“Is”或类似名称。

例如，比较：

if(Direction)    {/* do something */}
if(PowerSetting) {/* do something else */}

与：

if(DirectionIsUp) {/* do something */}
if(PowerIsOn)     {/* do something else */}

Flags are very useful - but give them sensible names, e.g. using "Is" or similar in their names.

For example, compare:

if(Direction)    {/* do something */}
if(PowerSetting) {/* do something else */}

with:

if(DirectionIsUp) {/* do something */}
if(PowerIsOn)     {/* do something else */}

回复收藏 0 原文

魄砕の薆 2024-07-25 11:22:35

如果它是可读的并且可以完成工作，那么它就没有问题。只需使用“has”和“is”前缀即可使其更具可读性：

var $isNewRecord;
var $hasUpdated;

if ($isNewRecord)
{
}

if ($hasUpdated)
{
}

If it is readable and does the job then there's nothing wrong with it. Just make use of "has" and "is" prefix to make it more readable:

var $isNewRecord;
var $hasUpdated;

if ($isNewRecord)
{
}

if ($hasUpdated)
{
}

回复收藏 0 原文

素罗衫 2024-07-25 11:22:35

请记住，该代码可以更容易地编写为

var1 = condition1

，如果使用得当，此分配将具有一些有用的属性。一个用例是命名一个复杂的计算，而不将其分解为一个函数：

user_is_on_fire = condition_that_holds_when_user_is_on_fire

这允许人们解释使用条件的含义，这通常从裸条件中并不明显。

如果评估条件的成本很高（或有副作用），则可能还需要在本地存储结果而不是重新评估条件。

一些警告：错误命名的标志往往会降低代码的可读性。设置在远离使用地点的标志也是如此。此外，想要使用标志这一事实是一种代码味道，表明人们应该考虑将条件分解为函数。

达阿

Bearing in mind that that code could be more readably written as

var1 = condition1

, this assignment has some useful properties if used well. One use case is to name a complicated calculation without breaking it out into a function:

user_is_on_fire = condition_that_holds_when_user_is_on_fire

That allows one to explain what one is using the condition to mean, which is often not obvious from the bare condition.

If evaluating the condition is expensive (or has side effects), it might also be desirable to store the result locally rather than reevaluate the condition.

Some caveats: Badly named flags will tend to make the code less readable. So will flags that are set far from the place where they are used. Also, the fact that one wants to use flags is a code smell suggesting that one should consider breaking the condition out into a function.

D'A

回复收藏 0 原文

舂唻埖巳落 2024-07-25 11:22:35

当您使用面向对象之前的语言时，可以将其称为“标志”。它们对于参数化一段代码的行为很有用。

然而，很快您就会发现代码很难理解。当您通过提供对可更改功能的引用来抽象出差异时，阅读/更改/维护会更容易。

在函数是一流公民的语言中（例如 Javascript、Haskell、Lisp...），这是轻而易举的事。

在OO语言中，你可以实现一些设计模式，比如抽象工厂、策略/策略……

太多的开关我个人认为是代码味道。

回复收藏 0 原文

雨后彩虹 2024-07-25 11:22:35

这取决于条件和使用次数。无论如何，重构为函数（如果条件计算速度慢，最好缓存结果）可能会给您带来更多可读的代码。

例如考虑这样的情况：

def checkCondition():
  import __builtin__ as cached
  try:
      return cached.conditionValue
  except NameError:
      cached.conditionValue = someSlowFunction()
      return cached.conditionValue

至于编码风格：

if（条件1） 
     变量1=真 
  别的 
     var1 = 假

我讨厌这样的代码。它应该是简单的：

var1 = condition1

或者如果你想确保结果是布尔值：

var1 = bool(condition1)

如果（var1 == true）

再次。糟糕的编码风格。它是：

if (var1)

That depends on the condition and how many times it's used. Anyway, refactoring into function (preferably caching the result if condition is slow to calculate) might give you a lot more readable code.

Consider for example this:

def checkCondition():
  import __builtin__ as cached
  try:
      return cached.conditionValue
  except NameError:
      cached.conditionValue = someSlowFunction()
      return cached.conditionValue

As for coding style:

if (condition1)
   var1= true
else
   var1 = false

I hate that kind of code. It should be either simply:

var1 = condition1

or if you want to assure that's result is boolean:

var1 = bool(condition1)

if (var1 == true)

Again. Bad coding style. It's:

if (var1)

回复收藏 0 原文

℉絮湮 2024-07-25 11:22:35

我不喜欢旗帜的地方是，当它们被称为旗帜时，没有任何评论。

例如，

void foo(...){

     bool flag;

    //begin some weird looking code

    if (something)
       [...]
      flag = true; 
 }

他们试图反对代码的可重写性。而那些在最初的程序员去世几个月/几年后才不得不阅读它的可怜人将很难理解它最初的目的是什么。

但是，如果标志变量有一个代表名称，那么我认为它们是可以的，只要明智地使用（请参阅其他回复）。

What i dont like about flags, is when they are called flags, with no comment whatsoever.

e.g

void foo(...){

     bool flag;

    //begin some weird looking code

    if (something)
       [...]
      flag = true; 
 }

They attempt against code redeability. And the poor guy who has to read it months/years after the original programmer is gone, is going to have some hard time trying to understand what the purposse of it originally was.

However, if the flag variable has a representative name, then i think they are ok, as long as used wisely (see other responses).

回复收藏 0 原文

鹤仙姿 2024-07-25 11:22:35

是的，这只是愚蠢无意义的代码。

您可以将这一切简化为：

if (condition1)
{
  // do something
}

Yes, that is just silly nonsensical code.

You can simplify all that down to:

if (condition1)
{
  // do something
}

回复收藏 0 原文

回眸一笑 2024-07-25 11:22:35

这是我的看法。
使用标志的代码：

...
if (dogIsBarking && smellsBad) {
  cleanupNeeded = true;
}
doOtherStuff();
... many lines later
if (cleanupNeeded) {
  startCleanup();
}
...

非常不干净。程序员只是碰巧按照他的想法告诉他的顺序进行编码。他只是在随机的地方添加了代码，以提醒自己稍后需要清理...他为什么不这样做：

...
doOtherStuff();
... many lines later
if (dogIsBarking && smellsBad) {
  startCleanup();
}
...

并且，按照 Robert Martin（清洁代码）的建议，可以将逻辑重构为更有意义的方法：

...
doSomeStuff();
... many lines later
if (dogTookADump()) {
  startCleanup();
}
...
boolean dogTookADump() {
  return (dogIsBarking && smellsBad);
}

所以，我见过很多很多代码，其中可以遵循上面这样的简单规则，但人们却无缘无故地不断添加复杂性和标志！现在，在某些情况下可能需要标志，但在大多数情况下，它们是程序员从过去继承的一种风格。

Here's my take.
Code using flags:

...
if (dogIsBarking && smellsBad) {
  cleanupNeeded = true;
}
doOtherStuff();
... many lines later
if (cleanupNeeded) {
  startCleanup();
}
...

Very unclean. The programmer simply happens to code in whatever order his mind tells him to. He just added code at a random place to remind himself that cleanup is needed later on... Why didn't he do this:

...
doOtherStuff();
... many lines later
if (dogIsBarking && smellsBad) {
  startCleanup();
}
...

And, following advise from Robert Martin (Clean Code), can refactor logic into more meaningful method:

...
doSomeStuff();
... many lines later
if (dogTookADump()) {
  startCleanup();
}
...
boolean dogTookADump() {
  return (dogIsBarking && smellsBad);
}

So, I have seen lots and lots of code where simple rules like above could be followed, yet people keep adding complications and flags for no reason! Now, there are legit cases where flags might be needed, but for most cases they are one style that programmers are carrying over from the past.

回复收藏 0 原文

~没有更多了~