Question

以下第二种缩进方法的一般意见是什么。

// Normal indentation
a.Value        = "foobar";
ab.Checked     = false;
foo.Value      = "foobar";
foobar.Checked = true;

// Spaces before the dot to align the properties/methods
a     .Value   = "foobar";
ab    .Checked = false;
foo   .Value   = "foobar";
foobar.Checked = true;

这应该是一个wiki，但我要么没有足够的权限，要么不知道如何更改它。

修改

我已经决定添加另一个示例来更好地展示这种缩进样式可能有用的地方。

fooA   .PropertyA = true;
foobarB.PropertyA = true;

使用VS2010中的新多行编辑功能，可以更轻松地更改所有行上的PropertyA。

在C＃中使用空格，甚至在点之前的换行都不常见（参见LINQ）。

Answer 1

点前的空格？亲爱的上帝没有！

Answer 2

我绝不会亲自使用。我会使用传统格式，例如：

a.Value = "foobar";
ab.Checked = false;
foo.Value = "foobar";
foobar.Checked = true;

我知道这可能不那么令人愉悦，但觉得其他人不那么理想理由是： -

难以维护：有时您可能拥有更小或更大的变量名称，或在代码中引入其他变量，这意味着您必须调整所有条目的格式。
自动格式化可能会搞砸了这个：如果您在按;时使用ReSharper（可能使用标准VS？），格式化会将其重新调整为行，所以你必须去这样做是为了确保它不会这样做。
我现在想不到一个，但我只能处理两点。

修改！想到另一点 。涉及更复杂的击键次数：例如，对于我使用ReSharper来实现后一格式化，我会输入foo，enter/tab（以确认自动完成），tab次X需要的标签数量可变长度（烦人），.，Value，tab以确认再次自动完成，=然后分配数据然后{{1}然后在Visual Studio中大喊大叫，因为我在第2点表达的所有非标准格式都被撤消了，所以最后按 CTRL + z 将恢复格式化我们刚刚。：）

Answer 3

我一直使用“正常缩进”。另一种方式对我来说似乎不太清楚，因为我不期待看到这种性质的缩进。

Answer 4

我只会在点之前使用空格，如果它们都是相同的属性/方法。如果它是混合属性，就像你在你的例子中那样，我会坚持使用'正常'。

但是，我认为这是一个没有实际意义的问题，因为Visual Studio autoformatter会在下次有人键入}以关闭任何封闭块时崩溃。

Answer 5

从C＃语言的角度来看是可以接受的。

与第二种相比，第一种风格对我来说更容易阅读。我认为这是因为dot之前的空格看起来很奇怪 - 在大多数书面语言中，dot之前没有空格。

我个人不与VS IDE抗争。默认样式对我来说很好。

请注意，使用比例字体完全打破了这种格式化（使用这样的字体对于编辑代码极其不寻常，但请四处询问。）

编辑：使用空格（+换行）表示流畅的界面看起来不错（http://en.wikipedia.org/wiki/Fluent_interface#C.23）。

Answer 6

我尝试了几次。看起来很不高兴。

我一直认为对齐'dot'可能会在正确的背景下工作：

// -----------------------
// decimal-style alignment
// -----------------------
     a.Value   = "foobar" ;
    ab.Checked = false    ;
   foo.Value   = "foobar" ;
foobar.Checked = true     ;

但是你会失去清晰的左边距，从而引导人们注意页面并保持你的缩进感。所以你要回到用它连接的标识符保持点。然而...

对齐等号是好的做法，因为它有助于订购整套：

// -----------------------
// tabular coding
// -----------------------
a.Value        = "foobar" ;
ab.Checked     = false    ;
foo.Value      = "foobar" ;
foobar.Checked = true     ;

一个人对一个人的代码施加的顺序越多，就越有可能发现一些不正确的事情。

解析器不关心整洁，可读的代码，但编译器不是代码的目标读者。你的目标受众是其他人，必须阅读并理解它。特别是可怜的笨蛋 - 可能是你！ - 必须匆忙拿起代码并在3年或5年后修复它，没有任何文档来帮助理解。

Answer 7

点之前的空格我永远不会这样做，因为当我正在阅读代码时，我会在看到空格时立即寻找一个点。点之后的空间，我过去做过，但几乎没有，我真的不想使用它。使用这样的样式的问题在于，即使它对你来说更具可读性，如果你从可能被认为是“规范”的事物中获得如此大的飞跃（意味着点之前的空格）那么你将会阻碍更多人而不是帮助。坚持团队或工作场所的标准是最重要的。即使它不是黑白标准，如果贵公司的其他99名开发人员使用VS标准，并且你把所有间距都放在你的点之前，它就不会有任何改进。

点之前有空格可以接受吗？

7 个答案: