Question

Code Complete表示始终使用块标识符是一种好习惯，无论是为了清晰还是作为防御措施。

自读这本书以来，我一直在虔诚地做这件事。有时它似乎过多，如下面的情况。

Steve McConnell是否有权坚持始终使用块标识符？您会使用以下哪些？

//naughty and brief
with myGrid do
  for currRow := FixedRows to RowCount - 1 do
    if RowChanged(currRow) then
      if not(RecordExists(currRow)) then
        InsertNewRecord(currRow)
      else
        UpdateExistingRecord(currRow);

//well behaved and verbose
with myGrid do begin
  for currRow := FixedRows to RowCount - 1 do begin
    if RowChanged(currRow) then begin
      if not(RecordExists(currRow)) then begin
        InsertNewRecord(currRow);
      end  //if it didn't exist, so insert it
      else begin
        UpdateExistingRecord(currRow);
      end;  //else it existed, so update it
    end;  //if any change
  end;  //for each row in the grid
end;  //with myGrid

Answer 1

我一直遵循'乖巧和冗长的'风格，除了那些不必要的额外注释。

以某种方式更有意义的是能够更快地查看代码并理解它，而不是在解密哪个块结束之前必须花费至少几秒钟。

提示：C＃的Visual Studio KB快捷方式跳转开始和结束：Ctrl +]

如果您使用Visual Studio，那么在块的开头和结尾处使用C＃的大括号也有助于您使用KB快捷方式跳转到开始和结束

Answer 2

我会使用我公司为其编码标准设定的任何一个。

话虽这么说，我宁愿使用第二个更冗长的块。阅读起来容易得多。但是，在某些情况下，我可能不会使用块结尾的注释。

Answer 3

就个人而言，我更喜欢第一个，因为恕我直言“结束”;不要告诉我太多，一旦一切都接近，我可以通过身份来判断会发生什么。

我认为在使用大型语句时，块更有用。您可以进行混合方法，在其中插入一些“开始...结束;”并注释它们结束的内容（例如将其用于with和第一个if）。

恕我直言，您也可以将其分解为更多方法，例如，

部分

  if not(RecordExists(currRow)) then begin
    InsertNewRecord(currRow);
  end  //if it didn't exist, so insert it
  else begin
    UpdateExistingRecord(currRow);
  end;  //else it existed, so update it

可以采用单独的方法。

Answer 4

我认为这在某种程度上取决于具体情况。有时您只需要这样的方法：

void Foo(bool state)
{
    if (state)
        TakeActionA();
    else
        TakeActionB();
}

我不知道如何使它看起来像这样：

void Foo(bool state)
{
    if (state)
    {
        TakeActionA();
    }
    else
    {
        TakeActionB();
    }
}

完全改善了可读性。

Answer 5

我是Python开发人员，因此我认为不需要块标识符。没有他们我很开心。缩进对我来说足够了。

Answer 6

块标识符不仅更容易阅读，如果您在if else逻辑中更改某些内容，或者只是添加一行并且不识别该行不在同一逻辑块中，那么它们更不容易出错的代码。

我会使用第二个代码块。第一个看起来更漂亮，更熟悉，但我认为这是语言问题，而不是块标识符

如果有可能，我会使用checkstyle来确保使用括号。

Answer 7

如果我没记错的话，CC也就评论提出了一些建议。特别是不要在评论中重写代码代码，而是解释为什么它会做什么。

Answer 8

我认为他是正确的，因为如果缩进不正确，代码仍可正确解释。我总是希望能够在浏览代码时找到循环的开始和结束块标识符，而不是依赖于正确的缩进。

Answer 9

永远不会总是这样或那样。因为我相信自己，我会使用更短，更简洁的风格。但是如果你处于团队环境中并不是每个人都具有相同的技能并且可维护性很重要，那么你可能想要选择后者。

Answer 10

我的下意识反应将是第二个上市（重复的评论从行的末尾删除，就像所有人一直在说的那样），但在更深入地思考之后，我会选择第一个加上一个或者两行有用的评论预先解释发生了什么（如果需要）。显然，在这个玩具示例中，即使是简明回答之前的评论也可能不需要，但在其他示例中可能也是如此。

屏幕上的代码较少（但仍然可读）且易于理解，有助于为IMO代码的未来部分保留大脑空间。

Answer 11

我喜欢那些喜欢更简洁代码的人。

看起来喜欢简洁版本的简洁版本更像是个人选择，而不是普遍适用。（好吧，在公司内部，它可能成为（小型）普遍规则。）

这就像过多的括号：有些人喜欢它，如(F1 and F2) or ((not F2) and F3)或(A - (B * C)) < 0，并不一定是因为他们不了解优先规则。他们就这么清楚了。

Answer 12

我投票给一个快乐的媒体。我将使用的规则是在内容为多行时使用包围关键字。在行动：

// clear and succinct
with myGrid do begin
  for currRow := FixedRows to RowCount - 1 do begin
    if RowChanged(currRow) then begin
      if not(RecordExists(currRow))
        InsertNewRecord(currRow);
      else
        UpdateExistingRecord(currRow);
    end;  // if RowChanged
  end;  // next currRow
end;  // with myGrid

Answer 13

评论结尾对于类似html的语言非常有用所以做错误的C代码就像无限连续的if / else / if / else

Answer 14

在代码行的末尾经常//注释（根据你的Well Behaved和Verbose示例）使代码更难以阅读imho - 当我看到它时我最终扫描'明显'的评论形式一些特别的，通常是在那里。

我更喜欢仅在显而易见的情况下评论（即整体和/或独特功能）

Answer 15

我个人建议始终在支持它们的语言中使用块标识符（但遵循公司的编码标准，如@ Muad'Dib建议的那样）。

原因在于，在非Pythonic语言中，空格（通常）对编译器没有意义，但它对人类有意义。

所以

with myGrid do
  for currRow := FixedRows to RowCount - 1 do
    if RowChanged(currRow) then
      Log(currRow);
      if not(RecordExists(currRow)) then
        InsertNewRecord(currRow)
      else
        UpdateExistingRecord(currRow);

似乎做了一件事，但做了一些完全不同的事情。

但是，我会删除行尾的评论。使用突出显示块的IDE。我认为Castalia将为Delphi做到这一点。您多久阅读一次代码打印输出？

我应该在代码中使用块标识符（“end;”）吗？

15 个答案: